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
d9148fb619
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.

8448 lines
235 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.
*/
chore(ui): regen types
2023-08-16 01:59:19 +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
export type paths = {
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/models/{base_model}/{model_type}/{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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +00:00
delete: operations["del_model"];
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Update Model
chore: regen types
2023-07-17 01:50:35 +00:00
* @description Update model contents with a new config. If the model name or base fields are changed, then the model is renamed.
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
patch: operations["update_model"];
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
};
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/models/import": {
chore(ui): regen types
2023-07-15 15:06:57 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Import Model
chore(ui): regen types
2023-07-15 15:06:57 +00:00
* @description Add a model using its local path, repo_id, or remote URL. Model characteristics will be probed and configured automatically
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
post: operations["import_model"];
chore(ui): regen types
2023-07-15 15:06:57 +00:00
};
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/models/add": {
chore(ui): regen types
2023-07-15 15:06:57 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Add Model
chore(ui): regen types
2023-07-15 15:06:57 +00:00
* @description Add a model using the configuration information appropriate for its type. Only local models can be added by path
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
post: operations["add_model"];
chore(ui): regen types
2023-07-15 15:06:57 +00:00
};
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/models/convert/{base_model}/{model_type}/{model_name}": {
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Convert Model
chore(ui): regen types
2023-07-15 15:06:57 +00:00
* @description Convert a checkpoint model into a diffusers model, optionally saving to the indicated destination directory, or `models` if none.
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
put: operations["convert_model"];
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
};
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/models/search": {
chore(ui): regen types
2023-07-15 15:06:57 +00:00
/** Search For Models */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
get: operations["search_for_models"];
chore(ui): regen types
2023-07-15 15:06:57 +00:00
};
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/models/ckpt_confs": {
chore(ui): regen types
2023-07-15 15:06:57 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* List Ckpt Configs
chore(ui): regen types
2023-07-15 15:06:57 +00:00
* @description Return a list of the legacy checkpoint configuration files stored in `ROOT/configs/stable-diffusion`, relative to ROOT.
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
get: operations["list_ckpt_configs"];
chore(ui): regen types
2023-07-15 15:06:57 +00:00
};
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/models/sync": {
chore(ui): regen types
2023-07-15 15:06:57 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Sync To Config
chore(ui): regen types
2023-07-15 15:06:57 +00:00
* @description Call after making changes to models.yaml, autoimport directories or models directory to synchronize
* in-memory data structures with disk data structures.
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
post: operations["sync_to_config"];
chore(ui): regen types
2023-07-15 15:06:57 +00:00
};
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/models/merge/{base_model}": {
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Merge Models
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
* @description Convert a checkpoint model into a diffusers model
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
put: operations["merge_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(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/images/upload": {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/images/i/{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(ui): typegen
2023-08-22 05:15:00 +00:00
* Get Image Dto
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description Gets an image's DTO
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
get: operations["get_image_dto"];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/images/clear-intermediates": {
Maryhipp/clear intermediates (#3820) * new route to clear intermediates * UI to clear intermediates from settings modal * cleanup * PR feedback --------- Co-authored-by: Mary Hipp <maryhipp@Marys-MacBook-Air.local>
2023-07-19 14:55:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Clear Intermediates
feat: Add ControlNet Resize Mode to Linear UI
2023-07-20 10:48:35 +00:00
* @description Clears all intermediates
Maryhipp/clear intermediates (#3820) * new route to clear intermediates * UI to clear intermediates from settings modal * cleanup * PR feedback --------- Co-authored-by: Mary Hipp <maryhipp@Marys-MacBook-Air.local>
2023-07-19 14:55:29 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
post: operations["clear_intermediates"];
Maryhipp/clear intermediates (#3820) * new route to clear intermediates * UI to clear intermediates from settings modal * cleanup * PR feedback --------- Co-authored-by: Mary Hipp <maryhipp@Marys-MacBook-Air.local>
2023-07-19 14:55:29 +00:00
};
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/images/i/{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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/images/i/{image_name}/full": {
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Get Image Full
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description Gets a full-resolution image file
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
get: operations["get_image_full"];
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Get Image Full
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* @description Gets a full-resolution image file
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
head: operations["get_image_full"];
chore(ui): regen types
2023-07-12 15:15:09 +00:00
};
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/images/i/{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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/images/i/{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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/images/": {
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* List Image Dtos
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
* @description Gets a list of image DTOs
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
get: operations["list_image_dtos"];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
};
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/images/delete": {
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
/** Delete Images From List */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
post: operations["delete_images_from_list"];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
};
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/images/star": {
rename pin to star, add multiselect and remove single image update api
2023-08-15 16:55:28 +00:00
/** Star Images In List */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
post: operations["star_images_in_list"];
rename pin to star, add multiselect and remove single image update api
2023-08-15 16:55:28 +00:00
};
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/images/unstar": {
rename pin to star, add multiselect and remove single image update api
2023-08-15 16:55:28 +00:00
/** Unstar Images In List */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
post: operations["unstar_images_in_list"];
rename pin to star, add multiselect and remove single image update api
2023-08-15 16:55:28 +00:00
};
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/boards/{board_id}/image_names": {
feat(ui): another go at gallery (#3791) * feat(ui): migrate listImages to RTK query using createEntityAdapter - see comments in `endpoints/images.ts` for explanation of the caching - so far, only manually updating `all` images when new image is generated. no other manual cache updates are implemented, but will be needed. - fixed some weirdness with loading state components (like the spinners in gallery) - added `useThumbnailFallback` for `IAIDndImage`, this displays the tiny webp thumbnail while the full-size images load - comment out some old thunk related stuff in gallerySlice, which is no longer needed * feat(ui): add manual cache updates for board changes (wip) - update RTK Query caches when adding/removing single image to/from board - work more on migrating all image-related operations to RTK Query * update AddImagesToBoardContext so that it works when user uses context menu + modal * handle case where no image is selected * get assets working for main list and boards - dnd only * feat(ui): migrate image uploads to RTK Query - minor refactor of `ImageUploader` and `useImageUploadButton` hooks, simplify some logic - style filesystem upload overlay to match existing UI - replace all old `imageUploaded` thunks with `uploadImage` RTK Query calls, update associated logic including canvas related uploads - simplify `PostUploadAction`s that only need to display user input * feat(ui): remove `receivedPageOfImages` thunks * feat(ui): remove `receivedImageUrls` thunk * feat(ui): finish removing all images thunks stuff now broken: - image usage - delete board images - on first load, no image selected * feat(ui): simplify `updateImage` cache manipulation - we don't actually ever change categories, so we can remove a lot of logic * feat(ui): simplify canvas autosave - instead of using a network request to set the canvas generation as not intermediate, we can just do that in the graph * feat(ui): simplify & handle edge cases in cache updates * feat(db, api): support `board_id='none'` for `get_many` images queries This allows us to get all images that are not on a board. * chore(ui): regen types * feat(ui): add `All Assets`, `No Board` boards Restructure boards: - `all images` is all images - `all assets` is all assets - `no board` is all images/assets without a board set - user boards may have images and assets Update caching logic - much simpler without every board having sub-views of images and assets - update drag and drop operations for all possible interactions * chore(ui): regen types * feat(ui): move download to top of context menu * feat(ui): improve drop overlay styles * fix(ui): fix image not selected on first load - listen for first load of all images board, then select the first image * feat(ui): refactor board deletion api changes: - add route to list all image names for a board. this is required to handle board + image deletion. we need to know every image in the board to determine the image usage across the app. this is fetched only when the delete board and images modal is opened so it's as efficient as it can be. - update the delete board route to respond with a list of deleted `board_images` and `images`, as image names. this is needed to perform accurate clientside state & cache updates after deleting. db changes: - remove unused `board_images` service method to get paginated images dtos for a board. this is now done thru the list images endpoint & images service. needs a small logic change on `images.delete_images_on_board` ui changes: - simplify the delete board modal - no context, just minor prop drilling. this is feasible for boards only because the components that need to trigger and manipulate the modal are very close together in the tree - add cache updates for `deleteBoard` & `deleteBoardAndImages` mutations - the only thing we cannot do directly is on `deleteBoardAndImages`, update the `No Board` board. we'd need to insert image dtos that we may not have loaded. instead, i am just invalidating the tags for that `listImages` cache. so when you `deleteBoardAndImages`, the `No Board` will re-fetch the initial image limit. i think this is more efficient than e.g. fetching all image dtos to insert then inserting them. - handle image usage for `deleteBoardAndImages` - update all (i think/hope) the little bits and pieces in the UI to accomodate these changes * fix(ui): fix board selection logic * feat(ui): add delete board modal loading state * fix(ui): use thumbnails for board cover images * fix(ui): fix race condition with board selection when selecting a board that doesn't have any images loaded, we need to wait until the images haveloaded before selecting the first image. this logic is debounced to ~1000ms. * feat(ui): name 'No Board' correctly, change icon * fix(ui): do not cache listAllImageNames query if we cache it, we can end up with stale image usage during deletion. we could of course manually update the cache as we are doing elsewhere. but because this is a relatively infrequent network request, i'd like to trade increased cache mgmt complexity here for increased resource usage. * feat(ui): reduce drag preview opacity, remove border * fix(ui): fix incorrect queryArg used in `deleteImage` and `updateImage` cache updates * fix(ui): fix doubled open in new tab * fix(ui): fix new generations not getting added to 'No Board' * fix(ui): fix board id not changing on new image when autosave enabled * fix(ui): context menu when selection is 0 need to revise how context menu is triggered later, when we approach multi select * fix(ui): fix deleting does not update counts for all images and all assets * fix(ui): fix all assets board name in boards list collapse button * fix(ui): ensure we never go under 0 for total board count * fix(ui): fix text overflow on board names --------- Co-authored-by: Mary Hipp <maryhipp@Marys-MacBook-Air.local>
2023-07-19 16:06:38 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* List All Board Image Names
feat(ui): another go at gallery (#3791) * feat(ui): migrate listImages to RTK query using createEntityAdapter - see comments in `endpoints/images.ts` for explanation of the caching - so far, only manually updating `all` images when new image is generated. no other manual cache updates are implemented, but will be needed. - fixed some weirdness with loading state components (like the spinners in gallery) - added `useThumbnailFallback` for `IAIDndImage`, this displays the tiny webp thumbnail while the full-size images load - comment out some old thunk related stuff in gallerySlice, which is no longer needed * feat(ui): add manual cache updates for board changes (wip) - update RTK Query caches when adding/removing single image to/from board - work more on migrating all image-related operations to RTK Query * update AddImagesToBoardContext so that it works when user uses context menu + modal * handle case where no image is selected * get assets working for main list and boards - dnd only * feat(ui): migrate image uploads to RTK Query - minor refactor of `ImageUploader` and `useImageUploadButton` hooks, simplify some logic - style filesystem upload overlay to match existing UI - replace all old `imageUploaded` thunks with `uploadImage` RTK Query calls, update associated logic including canvas related uploads - simplify `PostUploadAction`s that only need to display user input * feat(ui): remove `receivedPageOfImages` thunks * feat(ui): remove `receivedImageUrls` thunk * feat(ui): finish removing all images thunks stuff now broken: - image usage - delete board images - on first load, no image selected * feat(ui): simplify `updateImage` cache manipulation - we don't actually ever change categories, so we can remove a lot of logic * feat(ui): simplify canvas autosave - instead of using a network request to set the canvas generation as not intermediate, we can just do that in the graph * feat(ui): simplify & handle edge cases in cache updates * feat(db, api): support `board_id='none'` for `get_many` images queries This allows us to get all images that are not on a board. * chore(ui): regen types * feat(ui): add `All Assets`, `No Board` boards Restructure boards: - `all images` is all images - `all assets` is all assets - `no board` is all images/assets without a board set - user boards may have images and assets Update caching logic - much simpler without every board having sub-views of images and assets - update drag and drop operations for all possible interactions * chore(ui): regen types * feat(ui): move download to top of context menu * feat(ui): improve drop overlay styles * fix(ui): fix image not selected on first load - listen for first load of all images board, then select the first image * feat(ui): refactor board deletion api changes: - add route to list all image names for a board. this is required to handle board + image deletion. we need to know every image in the board to determine the image usage across the app. this is fetched only when the delete board and images modal is opened so it's as efficient as it can be. - update the delete board route to respond with a list of deleted `board_images` and `images`, as image names. this is needed to perform accurate clientside state & cache updates after deleting. db changes: - remove unused `board_images` service method to get paginated images dtos for a board. this is now done thru the list images endpoint & images service. needs a small logic change on `images.delete_images_on_board` ui changes: - simplify the delete board modal - no context, just minor prop drilling. this is feasible for boards only because the components that need to trigger and manipulate the modal are very close together in the tree - add cache updates for `deleteBoard` & `deleteBoardAndImages` mutations - the only thing we cannot do directly is on `deleteBoardAndImages`, update the `No Board` board. we'd need to insert image dtos that we may not have loaded. instead, i am just invalidating the tags for that `listImages` cache. so when you `deleteBoardAndImages`, the `No Board` will re-fetch the initial image limit. i think this is more efficient than e.g. fetching all image dtos to insert then inserting them. - handle image usage for `deleteBoardAndImages` - update all (i think/hope) the little bits and pieces in the UI to accomodate these changes * fix(ui): fix board selection logic * feat(ui): add delete board modal loading state * fix(ui): use thumbnails for board cover images * fix(ui): fix race condition with board selection when selecting a board that doesn't have any images loaded, we need to wait until the images haveloaded before selecting the first image. this logic is debounced to ~1000ms. * feat(ui): name 'No Board' correctly, change icon * fix(ui): do not cache listAllImageNames query if we cache it, we can end up with stale image usage during deletion. we could of course manually update the cache as we are doing elsewhere. but because this is a relatively infrequent network request, i'd like to trade increased cache mgmt complexity here for increased resource usage. * feat(ui): reduce drag preview opacity, remove border * fix(ui): fix incorrect queryArg used in `deleteImage` and `updateImage` cache updates * fix(ui): fix doubled open in new tab * fix(ui): fix new generations not getting added to 'No Board' * fix(ui): fix board id not changing on new image when autosave enabled * fix(ui): context menu when selection is 0 need to revise how context menu is triggered later, when we approach multi select * fix(ui): fix deleting does not update counts for all images and all assets * fix(ui): fix all assets board name in boards list collapse button * fix(ui): ensure we never go under 0 for total board count * fix(ui): fix text overflow on board names --------- Co-authored-by: Mary Hipp <maryhipp@Marys-MacBook-Air.local>
2023-07-19 16:06:38 +00:00
* @description Gets a list of images for a board
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
get: operations["list_all_board_image_names"];
feat(ui): another go at gallery (#3791) * feat(ui): migrate listImages to RTK query using createEntityAdapter - see comments in `endpoints/images.ts` for explanation of the caching - so far, only manually updating `all` images when new image is generated. no other manual cache updates are implemented, but will be needed. - fixed some weirdness with loading state components (like the spinners in gallery) - added `useThumbnailFallback` for `IAIDndImage`, this displays the tiny webp thumbnail while the full-size images load - comment out some old thunk related stuff in gallerySlice, which is no longer needed * feat(ui): add manual cache updates for board changes (wip) - update RTK Query caches when adding/removing single image to/from board - work more on migrating all image-related operations to RTK Query * update AddImagesToBoardContext so that it works when user uses context menu + modal * handle case where no image is selected * get assets working for main list and boards - dnd only * feat(ui): migrate image uploads to RTK Query - minor refactor of `ImageUploader` and `useImageUploadButton` hooks, simplify some logic - style filesystem upload overlay to match existing UI - replace all old `imageUploaded` thunks with `uploadImage` RTK Query calls, update associated logic including canvas related uploads - simplify `PostUploadAction`s that only need to display user input * feat(ui): remove `receivedPageOfImages` thunks * feat(ui): remove `receivedImageUrls` thunk * feat(ui): finish removing all images thunks stuff now broken: - image usage - delete board images - on first load, no image selected * feat(ui): simplify `updateImage` cache manipulation - we don't actually ever change categories, so we can remove a lot of logic * feat(ui): simplify canvas autosave - instead of using a network request to set the canvas generation as not intermediate, we can just do that in the graph * feat(ui): simplify & handle edge cases in cache updates * feat(db, api): support `board_id='none'` for `get_many` images queries This allows us to get all images that are not on a board. * chore(ui): regen types * feat(ui): add `All Assets`, `No Board` boards Restructure boards: - `all images` is all images - `all assets` is all assets - `no board` is all images/assets without a board set - user boards may have images and assets Update caching logic - much simpler without every board having sub-views of images and assets - update drag and drop operations for all possible interactions * chore(ui): regen types * feat(ui): move download to top of context menu * feat(ui): improve drop overlay styles * fix(ui): fix image not selected on first load - listen for first load of all images board, then select the first image * feat(ui): refactor board deletion api changes: - add route to list all image names for a board. this is required to handle board + image deletion. we need to know every image in the board to determine the image usage across the app. this is fetched only when the delete board and images modal is opened so it's as efficient as it can be. - update the delete board route to respond with a list of deleted `board_images` and `images`, as image names. this is needed to perform accurate clientside state & cache updates after deleting. db changes: - remove unused `board_images` service method to get paginated images dtos for a board. this is now done thru the list images endpoint & images service. needs a small logic change on `images.delete_images_on_board` ui changes: - simplify the delete board modal - no context, just minor prop drilling. this is feasible for boards only because the components that need to trigger and manipulate the modal are very close together in the tree - add cache updates for `deleteBoard` & `deleteBoardAndImages` mutations - the only thing we cannot do directly is on `deleteBoardAndImages`, update the `No Board` board. we'd need to insert image dtos that we may not have loaded. instead, i am just invalidating the tags for that `listImages` cache. so when you `deleteBoardAndImages`, the `No Board` will re-fetch the initial image limit. i think this is more efficient than e.g. fetching all image dtos to insert then inserting them. - handle image usage for `deleteBoardAndImages` - update all (i think/hope) the little bits and pieces in the UI to accomodate these changes * fix(ui): fix board selection logic * feat(ui): add delete board modal loading state * fix(ui): use thumbnails for board cover images * fix(ui): fix race condition with board selection when selecting a board that doesn't have any images loaded, we need to wait until the images haveloaded before selecting the first image. this logic is debounced to ~1000ms. * feat(ui): name 'No Board' correctly, change icon * fix(ui): do not cache listAllImageNames query if we cache it, we can end up with stale image usage during deletion. we could of course manually update the cache as we are doing elsewhere. but because this is a relatively infrequent network request, i'd like to trade increased cache mgmt complexity here for increased resource usage. * feat(ui): reduce drag preview opacity, remove border * fix(ui): fix incorrect queryArg used in `deleteImage` and `updateImage` cache updates * fix(ui): fix doubled open in new tab * fix(ui): fix new generations not getting added to 'No Board' * fix(ui): fix board id not changing on new image when autosave enabled * fix(ui): context menu when selection is 0 need to revise how context menu is triggered later, when we approach multi select * fix(ui): fix deleting does not update counts for all images and all assets * fix(ui): fix all assets board name in boards list collapse button * fix(ui): ensure we never go under 0 for total board count * fix(ui): fix text overflow on board names --------- Co-authored-by: Mary Hipp <maryhipp@Marys-MacBook-Air.local>
2023-07-19 16:06:38 +00:00
};
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Add Image To 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_image
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
post: operations["add_image_to_board"];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Remove Image From Board
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
* @description Removes an image from its board, if it had one
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
delete: operations["remove_image_from_board"];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
};
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/board_images/batch": {
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Add Images To Board
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
* @description Adds a list of images to a board
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
post: operations["add_images_to_board"];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
};
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/board_images/batch/delete": {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Remove Images From Board
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
* @description Removes a list of images from their board, if they had one
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
post: operations["remove_images_from_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(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/app/version": {
feat: Add App Version to UI
2023-07-08 09:31:17 +00:00
/** Get Version */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
get: operations["app_version"];
detect if user has patchmatch enabled
2023-07-12 15:56:40 +00:00
};
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/app/config": {
detect if user has patchmatch enabled
2023-07-12 15:56:40 +00:00
/** Get Config */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
get: operations["get_config"];
feat: Add App Version to UI
2023-07-08 09:31:17 +00:00
};
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"/api/v1/app/logging": {
merge with main
2023-07-20 15:45:54 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Get Log Level
merge with main
2023-07-20 15:45:54 +00:00
* @description Returns the log level
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
get: operations["get_log_level"];
merge with main
2023-07-20 15:45:54 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Set Log Level
merge with main
2023-07-20 15:45:54 +00:00
* @description Sets the log verbosity level
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
post: operations["set_log_level"];
merge with main
2023-07-20 15:45:54 +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
};
export type webhooks = Record<string, never>;
export type components = {
schemas: {
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
/** AddImagesToBoardResult */
AddImagesToBoardResult: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Board Id
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
* @description The id of the board the images were added to
*/
board_id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Added Image Names
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
* @description The image names that were added to the board
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
added_image_names: string[];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Add Integers
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default add
* @enum {string}
*/
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
};
feat: Add App Version to UI
2023-07-08 09:31:17 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* AppConfig
detect if user has patchmatch enabled
2023-07-12 15:56:40 +00:00
* @description App Config Response
*/
AppConfig: {
chore(ui): regen types
2023-07-13 05:22:18 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Infill Methods
chore(ui): regen types
2023-07-13 05:22:18 +00:00
* @description List of available infill methods
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
infill_methods: string[];
feat(ui): add nsfw & watermark to linear ui - add `addNSFWCheckerToGraph` and `addWatermarkerToGraph` functions - use them in all linear graph creation - add state & toggles to settings modal to enable these - trigger queries for app config on socket connect - disable the nsfw/watermark booleans if we get the app config and they are not available
2023-07-26 08:20:20 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Upscaling Methods
feat(ui): add nsfw & watermark to linear ui - add `addNSFWCheckerToGraph` and `addWatermarkerToGraph` functions - use them in all linear graph creation - add state & toggles to settings modal to enable these - trigger queries for app config on socket connect - disable the nsfw/watermark booleans if we get the app config and they are not available
2023-07-26 08:20:20 +00:00
* @description List of upscaling methods
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
upscaling_methods: components["schemas"]["Upscaler"][];
feat(ui): add nsfw & watermark to linear ui - add `addNSFWCheckerToGraph` and `addWatermarkerToGraph` functions - use them in all linear graph creation - add state & toggles to settings modal to enable these - trigger queries for app config on socket connect - disable the nsfw/watermark booleans if we get the app config and they are not available
2023-07-26 08:20:20 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Nsfw Methods
feat(ui): add nsfw & watermark to linear ui - add `addNSFWCheckerToGraph` and `addWatermarkerToGraph` functions - use them in all linear graph creation - add state & toggles to settings modal to enable these - trigger queries for app config on socket connect - disable the nsfw/watermark booleans if we get the app config and they are not available
2023-07-26 08:20:20 +00:00
* @description List of NSFW checking methods
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
nsfw_methods: string[];
feat(ui): add nsfw & watermark to linear ui - add `addNSFWCheckerToGraph` and `addWatermarkerToGraph` functions - use them in all linear graph creation - add state & toggles to settings modal to enable these - trigger queries for app config on socket connect - disable the nsfw/watermark booleans if we get the app config and they are not available
2023-07-26 08:20:20 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Watermarking Methods
feat(ui): add nsfw & watermark to linear ui - add `addNSFWCheckerToGraph` and `addWatermarkerToGraph` functions - use them in all linear graph creation - add state & toggles to settings modal to enable these - trigger queries for app config on socket connect - disable the nsfw/watermark booleans if we get the app config and they are not available
2023-07-26 08:20:20 +00:00
* @description List of invisible watermark methods
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
watermarking_methods: string[];
detect if user has patchmatch enabled
2023-07-12 15:56:40 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* AppVersion
feat: Add App Version to UI
2023-07-08 09:31:17 +00:00
* @description App Version Response
*/
AppVersion: {
chore(ui): regen types
2023-07-13 05:22:18 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Version
chore(ui): regen types
2023-07-13 05:22:18 +00:00
* @description App version
*/
feat: Add App Version to UI
2023-07-08 09:31:17 +00:00
version: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +00:00
BaseModelType: "sd-1" | "sd-2" | "sdxl" | "sdxl-refiner";
experimental: LaMa Infill
2023-08-23 19:25:24 +00:00
/**
* Blank Image
* @description Creates a blank image and forwards it to the pipeline
*/
BlankImageInvocation: {
/**
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
experimental: LaMa Infill
2023-08-23 19:25:24 +00:00
*/
id: string;
/**
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
experimental: LaMa Infill
2023-08-23 19:25:24 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
experimental: LaMa Infill
2023-08-23 19:25:24 +00:00
/**
* Width
* @description The width of the image
* @default 512
*/
width?: number;
/**
* Height
* @description The height of the image
* @default 512
*/
height?: number;
/**
* Mode
* @description The mode of the image
* @default RGB
* @enum {string}
*/
mode?: "RGB" | "RGBA";
/**
* Color
* @description The color of the image
* @default {
* "r": 0,
* "g": 0,
* "b": 0,
* "a": 255
* }
*/
color?: components["schemas"]["ColorField"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default blank_image
* @enum {string}
*/
type: "blank_image";
experimental: LaMa Infill
2023-08-23 19:25:24 +00:00
};
chore(ui): typegen
2023-08-22 05:15:00 +00:00
/**
* Blend Latents
* @description Blend two latents using a given alpha. Latents must have same size.
*/
BlendLatentsInvocation: {
/**
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
chore(ui): typegen
2023-08-22 05:15:00 +00:00
*/
id: string;
/**
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
chore(ui): typegen
2023-08-22 05:15:00 +00:00
/**
* Latents A
* @description Latents tensor
*/
latents_a?: components["schemas"]["LatentsField"];
/**
* Latents B
* @description Latents tensor
*/
latents_b?: components["schemas"]["LatentsField"];
/**
* Alpha
* @description Blending factor. 0.0 = use input A only, 1.0 = use input B only, 0.5 = 50% mix of input A and input B.
* @default 0.5
*/
alpha?: number;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default lblend
* @enum {string}
*/
type: "lblend";
chore(ui): typegen
2023-08-22 05:15:00 +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
/** BoardChanges */
BoardChanges: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
};
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
/** Body_add_image_to_board */
Body_add_image_to_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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
};
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
/** Body_add_images_to_board */
Body_add_images_to_board: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Board Id
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
* @description The id of the board to add to
*/
board_id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Image Names
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
* @description The names of the images to add
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
image_names: string[];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
};
/** Body_delete_images_from_list */
Body_delete_images_from_list: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Image Names
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
* @description The list of names of images to delete
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
image_names: string[];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
};
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/** Body_import_model */
Body_import_model: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Location
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
* @description A model path, repo_id or URL to import
*/
location: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Prediction Type
* @description Prediction type for SDv2 checkpoint files
* @default v_prediction
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
prediction_type?: "v_prediction" | "epsilon" | "sample";
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
};
/** Body_merge_models */
Body_merge_models: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Model Names
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
* @description model name
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
model_names: string[];
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Merged Model Name
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
* @description Name of destination model
*/
merged_model_name: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Alpha
* @description Alpha weighting strength to apply to 2d and 3d models
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
* @default 0.5
*/
alpha?: number;
/** @description Interpolation method */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
interp: components["schemas"]["MergeInterpolationMethod"];
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Force
* @description Force merging of models created with different versions of diffusers
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
* @default false
*/
force?: boolean;
chore(ui): regen types
2023-07-15 15:06:57 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Merge Dest Directory
chore(ui): regen types
2023-07-15 15:06:57 +00:00
* @description Save the merged model to the designated directory (with 'merged_model_name' appended)
*/
merge_dest_directory?: string;
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
};
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
/** Body_remove_image_from_board */
Body_remove_image_from_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(ui): typegen
2023-08-22 05:15:00 +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;
};
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
/** Body_remove_images_from_board */
Body_remove_images_from_board: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Image Names
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
* @description The names of the images to remove
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
image_names: string[];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
};
rename pin to star, add multiselect and remove single image update api
2023-08-15 16:55:28 +00:00
/** Body_star_images_in_list */
Body_star_images_in_list: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Image Names
rename pin to star, add multiselect and remove single image update api
2023-08-15 16:55:28 +00:00
* @description The list of names of images to star
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
image_names: string[];
rename pin to star, add multiselect and remove single image update api
2023-08-15 16:55:28 +00:00
};
/** Body_unstar_images_in_list */
Body_unstar_images_in_list: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Image Names
rename pin to star, add multiselect and remove single image update api
2023-08-15 16:55:28 +00:00
* @description The list of names of images to unstar
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
image_names: string[];
rename pin to star, add multiselect and remove single image update api
2023-08-15 16:55:28 +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
/** Body_upload_image */
Body_upload_image: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +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
*/
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
file: Blob;
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
/**
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* Boolean Collection Primitive
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
* @description A collection of boolean primitive values
*/
BooleanCollectionInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Collection
* @description The collection of boolean values
*/
collection?: boolean[];
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default boolean_collection
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
type: "boolean_collection";
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
};
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* BooleanCollectionOutput
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description Base class for nodes that output a collection of booleans
*/
BooleanCollectionOutput: {
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Collection
* @description The output boolean collection
*/
collection: boolean[];
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default boolean_collection_output
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @enum {string}
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19:36 +00:00
type: "boolean_collection_output";
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Boolean Primitive
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description A boolean primitive value
*/
BooleanInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Value
* @description The boolean value
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @default false
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19:36 +00:00
value?: boolean;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default boolean
* @enum {string}
*/
type: "boolean";
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* BooleanOutput
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description Base class for nodes that output a single boolean
*/
BooleanOutput: {
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Value
* @description The output boolean
*/
value: boolean;
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default boolean_output
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @enum {string}
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19:36 +00:00
type: "boolean_output";
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Canny 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
* @description Canny edge detection for ControlNet
*/
CannyImageProcessorInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Image
* @description The image to process
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
};
/** ClipField */
ClipField: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +00:00
text_encoder: components["schemas"]["ModelInfo"];
feat: Add Clip Skip To Linear UI
2023-07-06 17:57:39 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Skipped Layers
feat: Add Clip Skip To Linear UI
2023-07-06 17:57:39 +00:00
* @description Number of skipped layers in text_encoder
*/
skipped_layers: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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
};
feat: Add Clip Skip To Linear UI
2023-07-06 17:57:39 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* CLIP Skip
feat: Add Clip Skip To Linear UI
2023-07-06 17:57:39 +00:00
* @description Skip layers in clip text_encoder model.
*/
ClipSkipInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat: Add Clip Skip To Linear UI
2023-07-06 17:57:39 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat: Add Clip Skip To Linear UI
2023-07-06 17:57:39 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat: Add Clip Skip To Linear UI
2023-07-06 17:57:39 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* CLIP
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description CLIP (tokenizer, text encoder, LoRAs) and skipped layer count
feat: Add Clip Skip To Linear UI
2023-07-06 17:57:39 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
clip?: components["schemas"]["ClipField"];
feat: Add Clip Skip To Linear UI
2023-07-06 17:57:39 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Skipped Layers
* @description Number of layers to skip in text encoder
feat: Add Clip Skip To Linear UI
2023-07-06 17:57:39 +00:00
* @default 0
*/
skipped_layers?: number;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default clip_skip
* @enum {string}
*/
type: "clip_skip";
feat: Add Clip Skip To Linear UI
2023-07-06 17:57:39 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* ClipSkipInvocationOutput
feat: Add Clip Skip To Linear UI
2023-07-06 17:57:39 +00:00
* @description Clip skip node output
*/
ClipSkipInvocationOutput: {
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* CLIP
* @description CLIP (tokenizer, text encoder, LoRAs) and skipped layer count
*/
clip?: components["schemas"]["ClipField"];
feat: Add Clip Skip To Linear UI
2023-07-06 17:57:39 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default clip_skip_output
feat: Add Clip Skip To Linear UI
2023-07-06 17:57:39 +00:00
* @enum {string}
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19:36 +00:00
type: "clip_skip_output";
feat: Add Clip Skip To Linear UI
2023-07-06 17:57:39 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Collection 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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +00:00
collection?: unknown[];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default collect
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +00:00
* CollectInvocationOutput
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Base class for all invocation outputs.
*
* All invocation outputs must use the `@invocation_output` decorator to provide their unique 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
*/
CollectInvocationOutput: {
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Collection
* @description The collection of input items
*/
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(ui): typegen
2023-08-22 05:15:00 +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}
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19: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
};
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* ColorCollectionOutput
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description Base class for nodes that output a collection of colors
*/
ColorCollectionOutput: {
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Collection
* @description The output colors
*/
collection: components["schemas"]["ColorField"][];
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default color_collection_output
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @enum {string}
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19:36 +00:00
type: "color_collection_output";
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
};
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Color Correct
wip: Port Outpainting to new backend
2023-08-11 18:15:59 +00:00
* @description Shifts the colors of a target image to match the reference image, optionally
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* using a mask to only color-correct certain regions of the target image.
*/
ColorCorrectInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Image
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* @description The image to color-correct
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
image?: components["schemas"]["ImageField"];
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Reference
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* @description Reference image for color-correction
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
reference?: components["schemas"]["ImageField"];
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Mask
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* @description Mask to use when applying color-correction
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
mask?: components["schemas"]["ImageField"];
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Mask Blur Radius
* @description Mask blur radius
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* @default 8
*/
mask_blur_radius?: number;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default color_correct
* @enum {string}
*/
type: "color_correct";
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
};
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* ColorField
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description A color primitive 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
ColorField: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
};
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Color Primitive
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description A color primitive value
*/
ColorInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Color
* @description The color value
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @default {
* "r": 0,
* "g": 0,
* "b": 0,
* "a": 255
* }
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
color?: components["schemas"]["ColorField"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default color
* @enum {string}
*/
type: "color";
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* ColorOutput
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description Base class for nodes that output a single color
*/
ColorOutput: {
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Color
* @description The output color
*/
color: components["schemas"]["ColorField"];
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default color_output
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @enum {string}
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19:36 +00:00
type: "color_output";
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +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
/**
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +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 Parse prompt using compel package to conditioning.
*/
CompelInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Prompt
* @description Prompt to be parsed by Compel to create a conditioning tensor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default compel
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +00:00
* CLIP
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description CLIP (tokenizer, text encoder, LoRAs) and skipped layer 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
*/
chore(ui): regen types
2023-08-16 01:59:19 +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
};
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
/**
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* Conditioning Collection Primitive
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
* @description A collection of conditioning tensor primitive values
*/
ConditioningCollectionInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Collection
* @description The collection of conditioning tensors
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
collection?: components["schemas"]["ConditioningField"][];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default conditioning_collection
* @enum {string}
*/
type: "conditioning_collection";
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* ConditioningCollectionOutput
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description Base class for nodes that output a collection of conditioning tensors
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
ConditioningCollectionOutput: {
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Collection
* @description The output conditioning tensors
*/
collection: 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default conditioning_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}
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19:36 +00:00
type: "conditioning_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
};
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* ConditioningField
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
* @description A conditioning tensor primitive value
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +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
ConditioningField: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Conditioning Name
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description The name of conditioning tensor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
conditioning_name: string;
};
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Conditioning Primitive
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description A conditioning tensor primitive value
*/
ConditioningInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Conditioning
* @description Conditioning tensor
*/
conditioning?: components["schemas"]["ConditioningField"];
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default conditioning
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
type: "conditioning";
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* ConditioningOutput
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description Base class for nodes that output a single conditioning tensor
*/
ConditioningOutput: {
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Conditioning
* @description Conditioning tensor
*/
conditioning: components["schemas"]["ConditioningField"];
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default conditioning_output
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @enum {string}
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19:36 +00:00
type: "conditioning_output";
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Content Shuffle 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
* @description Applies content shuffle processing to image
*/
ContentShuffleImageProcessorInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Image
* @description The image to process
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Detect Resolution
* @description 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Image Resolution
* @description Pixel resolution for 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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
control_model: components["schemas"]["ControlNetModelField"];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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
*/
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
begin_step_percent?: 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(ui): typegen
2023-08-22 05:15:00 +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
*/
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
end_step_percent?: number;
chore(ui): regen api schema
2023-06-25 04:04:16 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +00:00
control_mode?: "balanced" | "more_prompt" | "more_control" | "unbalanced";
feat: Add ControlNet Resize Mode to Linear UI
2023-07-20 10:48:35 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Resize Mode
* @description The resize mode to use
* @default just_resize
feat: Add ControlNet Resize Mode to Linear UI
2023-07-20 10:48:35 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
resize_mode?: "just_resize" | "crop_resize" | "fill_resize" | "just_resize_simple";
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* 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
* @description Collects ControlNet info to pass to other nodes
*/
ControlNetInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Control Model
* @description ControlNet model to load
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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: polymorphic fields Initial support for polymorphic field types. Polymorphic types are a single of or list of a specific type. For example, `Union[str, list[str]]`. Polymorphics do not yet have support for direct input in the UI (will come in the future). They will be forcibly set as Connection-only fields, in which case users will not be able to provide direct input to the field. If a polymorphic should present as a singleton type - which would allow direct input - the node must provide an explicit type hint. For example, `DenoiseLatents`' `CFG Scale` is polymorphic, but in the node editor, we want to present this as a number input. In the node definition, the field is given `ui_type=UIType.Float`, which tells the UI to treat this as a `float` field. The connection validation logic will prevent connecting a collection to `CFG Scale` in this situation, because it is typed as `float`. The workaround is to disable validation from the settings to make this specific connection. A future improvement will resolve this. This also introduces better support for collection field types. Like polymorphics, collection types are parsed automatically by the client and do not need any specific type hints. Also like polymorphics, there is no support yet for direct input of collection types in the UI. - Disabling validation in workflow editor now displays the visual hints for valid connections, but lets you connect to anything. - Added `ui_order: int` to `InputField` and `OutputField`. The UI will use this, if present, to order fields in a node UI. See usage in `DenoiseLatents` for an example. - Updated the field colors - duplicate colors have just been lightened a bit. It's not perfect but it was a quick fix. - Field handles for collections are the same color as their single counterparts, but have a dark dot in the center of them. - Field handles for polymorphics are a rounded square with dot in the middle. - Removed all fields that just render `null` from `InputFieldRenderer`, replaced with a single fallback - Removed logic in `zValidatedWorkflow`, which checked for existence of node templates for each node in a workflow. This logic introduced a circular dependency, due to importing the global redux `store` in order to get the node templates within a zod schema. It's actually fine to just leave this out entirely; The case of a missing node template is handled by the UI. Fixing it otherwise would introduce a substantial headache. - Fixed the `ControlNetInvocation.control_model` field default, which was a string when it shouldn't have one.
2023-09-01 09:40:27 +00:00
control_model: components["schemas"]["ControlNetModelField"];
chore(ui): regen types
2023-07-13 05:22:18 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +00:00
control_mode?: "balanced" | "more_prompt" | "more_control" | "unbalanced";
feat: Add ControlNet Resize Mode to Linear UI
2023-07-20 10:48:35 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Resize Mode
* @description The resize mode used
* @default just_resize
feat: Add ControlNet Resize Mode to Linear UI
2023-07-20 10:48:35 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
resize_mode?: "just_resize" | "crop_resize" | "fill_resize" | "just_resize_simple";
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default controlnet
* @enum {string}
*/
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
};
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/** ControlNetModelCheckpointConfig */
ControlNetModelCheckpointConfig: {
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/** Model Name */
model_name: string;
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_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;
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Model Format
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_format: "checkpoint";
error?: components["schemas"]["ModelError"];
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/** Config */
config: string;
};
/** ControlNetModelDiffusersConfig */
ControlNetModelDiffusersConfig: {
/** Model Name */
model_name: string;
chore(ui): regen types
2023-08-16 01:59:19 +00:00
base_model: components["schemas"]["BaseModelType"];
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Model Type
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_type: "controlnet";
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/** Path */
path: string;
/** Description */
description?: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Model Format
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +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
};
chore(ui): typegen
2023-07-08 09:31:45 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* ControlNetModelField
chore(ui): typegen
2023-07-08 09:31:45 +00:00
* @description ControlNet model field
*/
ControlNetModelField: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Model Name
chore(ui): typegen
2023-07-08 09:31:45 +00:00
* @description Name of the ControlNet model
*/
model_name: string;
/** @description Base model */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
base_model: components["schemas"]["BaseModelType"];
chore(ui): typegen
2023-07-08 09:31:45 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Control
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description ControlNet(s) to apply
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
control: components["schemas"]["ControlField"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default control_output
* @enum {string}
*/
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(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* CoreMetadata
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description Core generation metadata for an image generated in InvokeAI.
*/
CoreMetadata: {
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* App Version
* @description The version of InvokeAI used to generate this image
chore: typegen
2023-09-02 01:36:07 +00:00
* @default 3.1.0
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
*/
app_version?: string;
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Generation Mode
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The generation mode that output this image
*/
generation_mode: string;
chore: Regen schema
2023-08-29 00:20:55 +00:00
/**
* Created By
* @description The name of the creator of the image
*/
created_by?: string;
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Positive Prompt
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The positive prompt parameter
*/
positive_prompt: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Negative Prompt
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The negative prompt parameter
*/
negative_prompt: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Width
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The width parameter
*/
width: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Height
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The height parameter
*/
height: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Seed
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The seed used for noise generation
*/
seed: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Rand Device
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The device used for random number generation
*/
rand_device: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Cfg Scale
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The classifier-free guidance scale parameter
*/
cfg_scale: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Steps
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The number of steps used for inference
*/
steps: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Scheduler
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The scheduler used for inference
*/
scheduler: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Clip Skip
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The number of skipped CLIP layers
*/
clip_skip: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Model
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The main model used for inference
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model: components["schemas"]["MainModelField"];
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Controlnets
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The ControlNets used for inference
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
controlnets: components["schemas"]["ControlField"][];
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Loras
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The LoRAs used for inference
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
loras: components["schemas"]["LoRAMetadataField"][];
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Vae
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
* @description The VAE used for decoding, if the main model's default was not used
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
vae?: components["schemas"]["VAEModelField"];
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Strength
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The strength used for latents-to-latents
*/
strength?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Init Image
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The name of the initial image
*/
init_image?: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Positive Style Prompt
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
* @description The positive style prompt parameter
chore(ui): regen types
2023-07-12 15:15:09 +00:00
*/
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
positive_style_prompt?: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Negative Style Prompt
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
* @description The negative style prompt parameter
*/
negative_style_prompt?: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Refiner Model
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
* @description The SDXL Refiner model used
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
refiner_model?: components["schemas"]["MainModelField"];
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Refiner Cfg Scale
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
* @description The classifier-free guidance scale parameter used for the refiner
*/
refiner_cfg_scale?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Refiner Steps
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
* @description The number of steps used for the refiner
*/
refiner_steps?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Refiner Scheduler
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
* @description The scheduler used for the refiner
*/
refiner_scheduler?: string;
/**
chore: typegen
2023-09-02 01:36:07 +00:00
* Refiner Positive Aesthetic Score
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
* @description The aesthetic score used for the refiner
*/
chore: typegen
2023-09-02 01:36:07 +00:00
refiner_positive_aesthetic_score?: number;
feat: Add SDXL Negative Aesthetic Score
2023-08-13 16:02:36 +00:00
/**
chore: typegen
2023-09-02 01:36:07 +00:00
* Refiner Negative Aesthetic Score
feat: Add SDXL Negative Aesthetic Score
2023-08-13 16:02:36 +00:00
* @description The aesthetic score used for the refiner
*/
chore: typegen
2023-09-02 01:36:07 +00:00
refiner_negative_aesthetic_score?: number;
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Refiner Start
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
* @description The start value used for refiner denoising
*/
refiner_start?: number;
chore(ui): regen types
2023-07-12 15:15:09 +00:00
};
chore: Regen schema
2023-08-29 00:20:55 +00:00
/**
* Create Denoise Mask
* @description Creates mask for denoising model run.
*/
CreateDenoiseMaskInvocation: {
/**
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
chore: Regen schema
2023-08-29 00:20:55 +00:00
*/
id: string;
/**
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
chore: Regen schema
2023-08-29 00:20:55 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
/**
* Vae
* @description VAE
*/
vae?: components["schemas"]["VaeField"];
/**
* Image
* @description Image which will be masked
*/
image?: components["schemas"]["ImageField"];
/**
* Mask
* @description The mask to use when pasting
*/
mask?: components["schemas"]["ImageField"];
/**
* Tiled
* @description Processing using overlapping tiles (reduce memory consumption)
* @default false
*/
tiled?: boolean;
/**
* Fp32
* @description Whether or not to use full float32 precision
* @default false
*/
fp32?: boolean;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default create_denoise_mask
* @enum {string}
*/
type: "create_denoise_mask";
chore: Regen schema
2023-08-29 00:20:55 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* OpenCV 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
* @description Simple inpaint using opencv.
*/
CvInpaintInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +00:00
mask?: components["schemas"]["ImageField"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default cv_inpaint
* @enum {string}
*/
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
};
feat(ui): another go at gallery (#3791) * feat(ui): migrate listImages to RTK query using createEntityAdapter - see comments in `endpoints/images.ts` for explanation of the caching - so far, only manually updating `all` images when new image is generated. no other manual cache updates are implemented, but will be needed. - fixed some weirdness with loading state components (like the spinners in gallery) - added `useThumbnailFallback` for `IAIDndImage`, this displays the tiny webp thumbnail while the full-size images load - comment out some old thunk related stuff in gallerySlice, which is no longer needed * feat(ui): add manual cache updates for board changes (wip) - update RTK Query caches when adding/removing single image to/from board - work more on migrating all image-related operations to RTK Query * update AddImagesToBoardContext so that it works when user uses context menu + modal * handle case where no image is selected * get assets working for main list and boards - dnd only * feat(ui): migrate image uploads to RTK Query - minor refactor of `ImageUploader` and `useImageUploadButton` hooks, simplify some logic - style filesystem upload overlay to match existing UI - replace all old `imageUploaded` thunks with `uploadImage` RTK Query calls, update associated logic including canvas related uploads - simplify `PostUploadAction`s that only need to display user input * feat(ui): remove `receivedPageOfImages` thunks * feat(ui): remove `receivedImageUrls` thunk * feat(ui): finish removing all images thunks stuff now broken: - image usage - delete board images - on first load, no image selected * feat(ui): simplify `updateImage` cache manipulation - we don't actually ever change categories, so we can remove a lot of logic * feat(ui): simplify canvas autosave - instead of using a network request to set the canvas generation as not intermediate, we can just do that in the graph * feat(ui): simplify & handle edge cases in cache updates * feat(db, api): support `board_id='none'` for `get_many` images queries This allows us to get all images that are not on a board. * chore(ui): regen types * feat(ui): add `All Assets`, `No Board` boards Restructure boards: - `all images` is all images - `all assets` is all assets - `no board` is all images/assets without a board set - user boards may have images and assets Update caching logic - much simpler without every board having sub-views of images and assets - update drag and drop operations for all possible interactions * chore(ui): regen types * feat(ui): move download to top of context menu * feat(ui): improve drop overlay styles * fix(ui): fix image not selected on first load - listen for first load of all images board, then select the first image * feat(ui): refactor board deletion api changes: - add route to list all image names for a board. this is required to handle board + image deletion. we need to know every image in the board to determine the image usage across the app. this is fetched only when the delete board and images modal is opened so it's as efficient as it can be. - update the delete board route to respond with a list of deleted `board_images` and `images`, as image names. this is needed to perform accurate clientside state & cache updates after deleting. db changes: - remove unused `board_images` service method to get paginated images dtos for a board. this is now done thru the list images endpoint & images service. needs a small logic change on `images.delete_images_on_board` ui changes: - simplify the delete board modal - no context, just minor prop drilling. this is feasible for boards only because the components that need to trigger and manipulate the modal are very close together in the tree - add cache updates for `deleteBoard` & `deleteBoardAndImages` mutations - the only thing we cannot do directly is on `deleteBoardAndImages`, update the `No Board` board. we'd need to insert image dtos that we may not have loaded. instead, i am just invalidating the tags for that `listImages` cache. so when you `deleteBoardAndImages`, the `No Board` will re-fetch the initial image limit. i think this is more efficient than e.g. fetching all image dtos to insert then inserting them. - handle image usage for `deleteBoardAndImages` - update all (i think/hope) the little bits and pieces in the UI to accomodate these changes * fix(ui): fix board selection logic * feat(ui): add delete board modal loading state * fix(ui): use thumbnails for board cover images * fix(ui): fix race condition with board selection when selecting a board that doesn't have any images loaded, we need to wait until the images haveloaded before selecting the first image. this logic is debounced to ~1000ms. * feat(ui): name 'No Board' correctly, change icon * fix(ui): do not cache listAllImageNames query if we cache it, we can end up with stale image usage during deletion. we could of course manually update the cache as we are doing elsewhere. but because this is a relatively infrequent network request, i'd like to trade increased cache mgmt complexity here for increased resource usage. * feat(ui): reduce drag preview opacity, remove border * fix(ui): fix incorrect queryArg used in `deleteImage` and `updateImage` cache updates * fix(ui): fix doubled open in new tab * fix(ui): fix new generations not getting added to 'No Board' * fix(ui): fix board id not changing on new image when autosave enabled * fix(ui): context menu when selection is 0 need to revise how context menu is triggered later, when we approach multi select * fix(ui): fix deleting does not update counts for all images and all assets * fix(ui): fix all assets board name in boards list collapse button * fix(ui): ensure we never go under 0 for total board count * fix(ui): fix text overflow on board names --------- Co-authored-by: Mary Hipp <maryhipp@Marys-MacBook-Air.local>
2023-07-19 16:06:38 +00:00
/** DeleteBoardResult */
DeleteBoardResult: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Board Id
feat(ui): another go at gallery (#3791) * feat(ui): migrate listImages to RTK query using createEntityAdapter - see comments in `endpoints/images.ts` for explanation of the caching - so far, only manually updating `all` images when new image is generated. no other manual cache updates are implemented, but will be needed. - fixed some weirdness with loading state components (like the spinners in gallery) - added `useThumbnailFallback` for `IAIDndImage`, this displays the tiny webp thumbnail while the full-size images load - comment out some old thunk related stuff in gallerySlice, which is no longer needed * feat(ui): add manual cache updates for board changes (wip) - update RTK Query caches when adding/removing single image to/from board - work more on migrating all image-related operations to RTK Query * update AddImagesToBoardContext so that it works when user uses context menu + modal * handle case where no image is selected * get assets working for main list and boards - dnd only * feat(ui): migrate image uploads to RTK Query - minor refactor of `ImageUploader` and `useImageUploadButton` hooks, simplify some logic - style filesystem upload overlay to match existing UI - replace all old `imageUploaded` thunks with `uploadImage` RTK Query calls, update associated logic including canvas related uploads - simplify `PostUploadAction`s that only need to display user input * feat(ui): remove `receivedPageOfImages` thunks * feat(ui): remove `receivedImageUrls` thunk * feat(ui): finish removing all images thunks stuff now broken: - image usage - delete board images - on first load, no image selected * feat(ui): simplify `updateImage` cache manipulation - we don't actually ever change categories, so we can remove a lot of logic * feat(ui): simplify canvas autosave - instead of using a network request to set the canvas generation as not intermediate, we can just do that in the graph * feat(ui): simplify & handle edge cases in cache updates * feat(db, api): support `board_id='none'` for `get_many` images queries This allows us to get all images that are not on a board. * chore(ui): regen types * feat(ui): add `All Assets`, `No Board` boards Restructure boards: - `all images` is all images - `all assets` is all assets - `no board` is all images/assets without a board set - user boards may have images and assets Update caching logic - much simpler without every board having sub-views of images and assets - update drag and drop operations for all possible interactions * chore(ui): regen types * feat(ui): move download to top of context menu * feat(ui): improve drop overlay styles * fix(ui): fix image not selected on first load - listen for first load of all images board, then select the first image * feat(ui): refactor board deletion api changes: - add route to list all image names for a board. this is required to handle board + image deletion. we need to know every image in the board to determine the image usage across the app. this is fetched only when the delete board and images modal is opened so it's as efficient as it can be. - update the delete board route to respond with a list of deleted `board_images` and `images`, as image names. this is needed to perform accurate clientside state & cache updates after deleting. db changes: - remove unused `board_images` service method to get paginated images dtos for a board. this is now done thru the list images endpoint & images service. needs a small logic change on `images.delete_images_on_board` ui changes: - simplify the delete board modal - no context, just minor prop drilling. this is feasible for boards only because the components that need to trigger and manipulate the modal are very close together in the tree - add cache updates for `deleteBoard` & `deleteBoardAndImages` mutations - the only thing we cannot do directly is on `deleteBoardAndImages`, update the `No Board` board. we'd need to insert image dtos that we may not have loaded. instead, i am just invalidating the tags for that `listImages` cache. so when you `deleteBoardAndImages`, the `No Board` will re-fetch the initial image limit. i think this is more efficient than e.g. fetching all image dtos to insert then inserting them. - handle image usage for `deleteBoardAndImages` - update all (i think/hope) the little bits and pieces in the UI to accomodate these changes * fix(ui): fix board selection logic * feat(ui): add delete board modal loading state * fix(ui): use thumbnails for board cover images * fix(ui): fix race condition with board selection when selecting a board that doesn't have any images loaded, we need to wait until the images haveloaded before selecting the first image. this logic is debounced to ~1000ms. * feat(ui): name 'No Board' correctly, change icon * fix(ui): do not cache listAllImageNames query if we cache it, we can end up with stale image usage during deletion. we could of course manually update the cache as we are doing elsewhere. but because this is a relatively infrequent network request, i'd like to trade increased cache mgmt complexity here for increased resource usage. * feat(ui): reduce drag preview opacity, remove border * fix(ui): fix incorrect queryArg used in `deleteImage` and `updateImage` cache updates * fix(ui): fix doubled open in new tab * fix(ui): fix new generations not getting added to 'No Board' * fix(ui): fix board id not changing on new image when autosave enabled * fix(ui): context menu when selection is 0 need to revise how context menu is triggered later, when we approach multi select * fix(ui): fix deleting does not update counts for all images and all assets * fix(ui): fix all assets board name in boards list collapse button * fix(ui): ensure we never go under 0 for total board count * fix(ui): fix text overflow on board names --------- Co-authored-by: Mary Hipp <maryhipp@Marys-MacBook-Air.local>
2023-07-19 16:06:38 +00:00
* @description The id of the board that was deleted.
*/
board_id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Deleted Board Images
feat(ui): another go at gallery (#3791) * feat(ui): migrate listImages to RTK query using createEntityAdapter - see comments in `endpoints/images.ts` for explanation of the caching - so far, only manually updating `all` images when new image is generated. no other manual cache updates are implemented, but will be needed. - fixed some weirdness with loading state components (like the spinners in gallery) - added `useThumbnailFallback` for `IAIDndImage`, this displays the tiny webp thumbnail while the full-size images load - comment out some old thunk related stuff in gallerySlice, which is no longer needed * feat(ui): add manual cache updates for board changes (wip) - update RTK Query caches when adding/removing single image to/from board - work more on migrating all image-related operations to RTK Query * update AddImagesToBoardContext so that it works when user uses context menu + modal * handle case where no image is selected * get assets working for main list and boards - dnd only * feat(ui): migrate image uploads to RTK Query - minor refactor of `ImageUploader` and `useImageUploadButton` hooks, simplify some logic - style filesystem upload overlay to match existing UI - replace all old `imageUploaded` thunks with `uploadImage` RTK Query calls, update associated logic including canvas related uploads - simplify `PostUploadAction`s that only need to display user input * feat(ui): remove `receivedPageOfImages` thunks * feat(ui): remove `receivedImageUrls` thunk * feat(ui): finish removing all images thunks stuff now broken: - image usage - delete board images - on first load, no image selected * feat(ui): simplify `updateImage` cache manipulation - we don't actually ever change categories, so we can remove a lot of logic * feat(ui): simplify canvas autosave - instead of using a network request to set the canvas generation as not intermediate, we can just do that in the graph * feat(ui): simplify & handle edge cases in cache updates * feat(db, api): support `board_id='none'` for `get_many` images queries This allows us to get all images that are not on a board. * chore(ui): regen types * feat(ui): add `All Assets`, `No Board` boards Restructure boards: - `all images` is all images - `all assets` is all assets - `no board` is all images/assets without a board set - user boards may have images and assets Update caching logic - much simpler without every board having sub-views of images and assets - update drag and drop operations for all possible interactions * chore(ui): regen types * feat(ui): move download to top of context menu * feat(ui): improve drop overlay styles * fix(ui): fix image not selected on first load - listen for first load of all images board, then select the first image * feat(ui): refactor board deletion api changes: - add route to list all image names for a board. this is required to handle board + image deletion. we need to know every image in the board to determine the image usage across the app. this is fetched only when the delete board and images modal is opened so it's as efficient as it can be. - update the delete board route to respond with a list of deleted `board_images` and `images`, as image names. this is needed to perform accurate clientside state & cache updates after deleting. db changes: - remove unused `board_images` service method to get paginated images dtos for a board. this is now done thru the list images endpoint & images service. needs a small logic change on `images.delete_images_on_board` ui changes: - simplify the delete board modal - no context, just minor prop drilling. this is feasible for boards only because the components that need to trigger and manipulate the modal are very close together in the tree - add cache updates for `deleteBoard` & `deleteBoardAndImages` mutations - the only thing we cannot do directly is on `deleteBoardAndImages`, update the `No Board` board. we'd need to insert image dtos that we may not have loaded. instead, i am just invalidating the tags for that `listImages` cache. so when you `deleteBoardAndImages`, the `No Board` will re-fetch the initial image limit. i think this is more efficient than e.g. fetching all image dtos to insert then inserting them. - handle image usage for `deleteBoardAndImages` - update all (i think/hope) the little bits and pieces in the UI to accomodate these changes * fix(ui): fix board selection logic * feat(ui): add delete board modal loading state * fix(ui): use thumbnails for board cover images * fix(ui): fix race condition with board selection when selecting a board that doesn't have any images loaded, we need to wait until the images haveloaded before selecting the first image. this logic is debounced to ~1000ms. * feat(ui): name 'No Board' correctly, change icon * fix(ui): do not cache listAllImageNames query if we cache it, we can end up with stale image usage during deletion. we could of course manually update the cache as we are doing elsewhere. but because this is a relatively infrequent network request, i'd like to trade increased cache mgmt complexity here for increased resource usage. * feat(ui): reduce drag preview opacity, remove border * fix(ui): fix incorrect queryArg used in `deleteImage` and `updateImage` cache updates * fix(ui): fix doubled open in new tab * fix(ui): fix new generations not getting added to 'No Board' * fix(ui): fix board id not changing on new image when autosave enabled * fix(ui): context menu when selection is 0 need to revise how context menu is triggered later, when we approach multi select * fix(ui): fix deleting does not update counts for all images and all assets * fix(ui): fix all assets board name in boards list collapse button * fix(ui): ensure we never go under 0 for total board count * fix(ui): fix text overflow on board names --------- Co-authored-by: Mary Hipp <maryhipp@Marys-MacBook-Air.local>
2023-07-19 16:06:38 +00:00
* @description The image names of the board-images relationships that were deleted.
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
deleted_board_images: string[];
feat(ui): another go at gallery (#3791) * feat(ui): migrate listImages to RTK query using createEntityAdapter - see comments in `endpoints/images.ts` for explanation of the caching - so far, only manually updating `all` images when new image is generated. no other manual cache updates are implemented, but will be needed. - fixed some weirdness with loading state components (like the spinners in gallery) - added `useThumbnailFallback` for `IAIDndImage`, this displays the tiny webp thumbnail while the full-size images load - comment out some old thunk related stuff in gallerySlice, which is no longer needed * feat(ui): add manual cache updates for board changes (wip) - update RTK Query caches when adding/removing single image to/from board - work more on migrating all image-related operations to RTK Query * update AddImagesToBoardContext so that it works when user uses context menu + modal * handle case where no image is selected * get assets working for main list and boards - dnd only * feat(ui): migrate image uploads to RTK Query - minor refactor of `ImageUploader` and `useImageUploadButton` hooks, simplify some logic - style filesystem upload overlay to match existing UI - replace all old `imageUploaded` thunks with `uploadImage` RTK Query calls, update associated logic including canvas related uploads - simplify `PostUploadAction`s that only need to display user input * feat(ui): remove `receivedPageOfImages` thunks * feat(ui): remove `receivedImageUrls` thunk * feat(ui): finish removing all images thunks stuff now broken: - image usage - delete board images - on first load, no image selected * feat(ui): simplify `updateImage` cache manipulation - we don't actually ever change categories, so we can remove a lot of logic * feat(ui): simplify canvas autosave - instead of using a network request to set the canvas generation as not intermediate, we can just do that in the graph * feat(ui): simplify & handle edge cases in cache updates * feat(db, api): support `board_id='none'` for `get_many` images queries This allows us to get all images that are not on a board. * chore(ui): regen types * feat(ui): add `All Assets`, `No Board` boards Restructure boards: - `all images` is all images - `all assets` is all assets - `no board` is all images/assets without a board set - user boards may have images and assets Update caching logic - much simpler without every board having sub-views of images and assets - update drag and drop operations for all possible interactions * chore(ui): regen types * feat(ui): move download to top of context menu * feat(ui): improve drop overlay styles * fix(ui): fix image not selected on first load - listen for first load of all images board, then select the first image * feat(ui): refactor board deletion api changes: - add route to list all image names for a board. this is required to handle board + image deletion. we need to know every image in the board to determine the image usage across the app. this is fetched only when the delete board and images modal is opened so it's as efficient as it can be. - update the delete board route to respond with a list of deleted `board_images` and `images`, as image names. this is needed to perform accurate clientside state & cache updates after deleting. db changes: - remove unused `board_images` service method to get paginated images dtos for a board. this is now done thru the list images endpoint & images service. needs a small logic change on `images.delete_images_on_board` ui changes: - simplify the delete board modal - no context, just minor prop drilling. this is feasible for boards only because the components that need to trigger and manipulate the modal are very close together in the tree - add cache updates for `deleteBoard` & `deleteBoardAndImages` mutations - the only thing we cannot do directly is on `deleteBoardAndImages`, update the `No Board` board. we'd need to insert image dtos that we may not have loaded. instead, i am just invalidating the tags for that `listImages` cache. so when you `deleteBoardAndImages`, the `No Board` will re-fetch the initial image limit. i think this is more efficient than e.g. fetching all image dtos to insert then inserting them. - handle image usage for `deleteBoardAndImages` - update all (i think/hope) the little bits and pieces in the UI to accomodate these changes * fix(ui): fix board selection logic * feat(ui): add delete board modal loading state * fix(ui): use thumbnails for board cover images * fix(ui): fix race condition with board selection when selecting a board that doesn't have any images loaded, we need to wait until the images haveloaded before selecting the first image. this logic is debounced to ~1000ms. * feat(ui): name 'No Board' correctly, change icon * fix(ui): do not cache listAllImageNames query if we cache it, we can end up with stale image usage during deletion. we could of course manually update the cache as we are doing elsewhere. but because this is a relatively infrequent network request, i'd like to trade increased cache mgmt complexity here for increased resource usage. * feat(ui): reduce drag preview opacity, remove border * fix(ui): fix incorrect queryArg used in `deleteImage` and `updateImage` cache updates * fix(ui): fix doubled open in new tab * fix(ui): fix new generations not getting added to 'No Board' * fix(ui): fix board id not changing on new image when autosave enabled * fix(ui): context menu when selection is 0 need to revise how context menu is triggered later, when we approach multi select * fix(ui): fix deleting does not update counts for all images and all assets * fix(ui): fix all assets board name in boards list collapse button * fix(ui): ensure we never go under 0 for total board count * fix(ui): fix text overflow on board names --------- Co-authored-by: Mary Hipp <maryhipp@Marys-MacBook-Air.local>
2023-07-19 16:06:38 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Deleted Images
feat(ui): another go at gallery (#3791) * feat(ui): migrate listImages to RTK query using createEntityAdapter - see comments in `endpoints/images.ts` for explanation of the caching - so far, only manually updating `all` images when new image is generated. no other manual cache updates are implemented, but will be needed. - fixed some weirdness with loading state components (like the spinners in gallery) - added `useThumbnailFallback` for `IAIDndImage`, this displays the tiny webp thumbnail while the full-size images load - comment out some old thunk related stuff in gallerySlice, which is no longer needed * feat(ui): add manual cache updates for board changes (wip) - update RTK Query caches when adding/removing single image to/from board - work more on migrating all image-related operations to RTK Query * update AddImagesToBoardContext so that it works when user uses context menu + modal * handle case where no image is selected * get assets working for main list and boards - dnd only * feat(ui): migrate image uploads to RTK Query - minor refactor of `ImageUploader` and `useImageUploadButton` hooks, simplify some logic - style filesystem upload overlay to match existing UI - replace all old `imageUploaded` thunks with `uploadImage` RTK Query calls, update associated logic including canvas related uploads - simplify `PostUploadAction`s that only need to display user input * feat(ui): remove `receivedPageOfImages` thunks * feat(ui): remove `receivedImageUrls` thunk * feat(ui): finish removing all images thunks stuff now broken: - image usage - delete board images - on first load, no image selected * feat(ui): simplify `updateImage` cache manipulation - we don't actually ever change categories, so we can remove a lot of logic * feat(ui): simplify canvas autosave - instead of using a network request to set the canvas generation as not intermediate, we can just do that in the graph * feat(ui): simplify & handle edge cases in cache updates * feat(db, api): support `board_id='none'` for `get_many` images queries This allows us to get all images that are not on a board. * chore(ui): regen types * feat(ui): add `All Assets`, `No Board` boards Restructure boards: - `all images` is all images - `all assets` is all assets - `no board` is all images/assets without a board set - user boards may have images and assets Update caching logic - much simpler without every board having sub-views of images and assets - update drag and drop operations for all possible interactions * chore(ui): regen types * feat(ui): move download to top of context menu * feat(ui): improve drop overlay styles * fix(ui): fix image not selected on first load - listen for first load of all images board, then select the first image * feat(ui): refactor board deletion api changes: - add route to list all image names for a board. this is required to handle board + image deletion. we need to know every image in the board to determine the image usage across the app. this is fetched only when the delete board and images modal is opened so it's as efficient as it can be. - update the delete board route to respond with a list of deleted `board_images` and `images`, as image names. this is needed to perform accurate clientside state & cache updates after deleting. db changes: - remove unused `board_images` service method to get paginated images dtos for a board. this is now done thru the list images endpoint & images service. needs a small logic change on `images.delete_images_on_board` ui changes: - simplify the delete board modal - no context, just minor prop drilling. this is feasible for boards only because the components that need to trigger and manipulate the modal are very close together in the tree - add cache updates for `deleteBoard` & `deleteBoardAndImages` mutations - the only thing we cannot do directly is on `deleteBoardAndImages`, update the `No Board` board. we'd need to insert image dtos that we may not have loaded. instead, i am just invalidating the tags for that `listImages` cache. so when you `deleteBoardAndImages`, the `No Board` will re-fetch the initial image limit. i think this is more efficient than e.g. fetching all image dtos to insert then inserting them. - handle image usage for `deleteBoardAndImages` - update all (i think/hope) the little bits and pieces in the UI to accomodate these changes * fix(ui): fix board selection logic * feat(ui): add delete board modal loading state * fix(ui): use thumbnails for board cover images * fix(ui): fix race condition with board selection when selecting a board that doesn't have any images loaded, we need to wait until the images haveloaded before selecting the first image. this logic is debounced to ~1000ms. * feat(ui): name 'No Board' correctly, change icon * fix(ui): do not cache listAllImageNames query if we cache it, we can end up with stale image usage during deletion. we could of course manually update the cache as we are doing elsewhere. but because this is a relatively infrequent network request, i'd like to trade increased cache mgmt complexity here for increased resource usage. * feat(ui): reduce drag preview opacity, remove border * fix(ui): fix incorrect queryArg used in `deleteImage` and `updateImage` cache updates * fix(ui): fix doubled open in new tab * fix(ui): fix new generations not getting added to 'No Board' * fix(ui): fix board id not changing on new image when autosave enabled * fix(ui): context menu when selection is 0 need to revise how context menu is triggered later, when we approach multi select * fix(ui): fix deleting does not update counts for all images and all assets * fix(ui): fix all assets board name in boards list collapse button * fix(ui): ensure we never go under 0 for total board count * fix(ui): fix text overflow on board names --------- Co-authored-by: Mary Hipp <maryhipp@Marys-MacBook-Air.local>
2023-07-19 16:06:38 +00:00
* @description The names of the images that were deleted.
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
deleted_images: string[];
feat(ui): another go at gallery (#3791) * feat(ui): migrate listImages to RTK query using createEntityAdapter - see comments in `endpoints/images.ts` for explanation of the caching - so far, only manually updating `all` images when new image is generated. no other manual cache updates are implemented, but will be needed. - fixed some weirdness with loading state components (like the spinners in gallery) - added `useThumbnailFallback` for `IAIDndImage`, this displays the tiny webp thumbnail while the full-size images load - comment out some old thunk related stuff in gallerySlice, which is no longer needed * feat(ui): add manual cache updates for board changes (wip) - update RTK Query caches when adding/removing single image to/from board - work more on migrating all image-related operations to RTK Query * update AddImagesToBoardContext so that it works when user uses context menu + modal * handle case where no image is selected * get assets working for main list and boards - dnd only * feat(ui): migrate image uploads to RTK Query - minor refactor of `ImageUploader` and `useImageUploadButton` hooks, simplify some logic - style filesystem upload overlay to match existing UI - replace all old `imageUploaded` thunks with `uploadImage` RTK Query calls, update associated logic including canvas related uploads - simplify `PostUploadAction`s that only need to display user input * feat(ui): remove `receivedPageOfImages` thunks * feat(ui): remove `receivedImageUrls` thunk * feat(ui): finish removing all images thunks stuff now broken: - image usage - delete board images - on first load, no image selected * feat(ui): simplify `updateImage` cache manipulation - we don't actually ever change categories, so we can remove a lot of logic * feat(ui): simplify canvas autosave - instead of using a network request to set the canvas generation as not intermediate, we can just do that in the graph * feat(ui): simplify & handle edge cases in cache updates * feat(db, api): support `board_id='none'` for `get_many` images queries This allows us to get all images that are not on a board. * chore(ui): regen types * feat(ui): add `All Assets`, `No Board` boards Restructure boards: - `all images` is all images - `all assets` is all assets - `no board` is all images/assets without a board set - user boards may have images and assets Update caching logic - much simpler without every board having sub-views of images and assets - update drag and drop operations for all possible interactions * chore(ui): regen types * feat(ui): move download to top of context menu * feat(ui): improve drop overlay styles * fix(ui): fix image not selected on first load - listen for first load of all images board, then select the first image * feat(ui): refactor board deletion api changes: - add route to list all image names for a board. this is required to handle board + image deletion. we need to know every image in the board to determine the image usage across the app. this is fetched only when the delete board and images modal is opened so it's as efficient as it can be. - update the delete board route to respond with a list of deleted `board_images` and `images`, as image names. this is needed to perform accurate clientside state & cache updates after deleting. db changes: - remove unused `board_images` service method to get paginated images dtos for a board. this is now done thru the list images endpoint & images service. needs a small logic change on `images.delete_images_on_board` ui changes: - simplify the delete board modal - no context, just minor prop drilling. this is feasible for boards only because the components that need to trigger and manipulate the modal are very close together in the tree - add cache updates for `deleteBoard` & `deleteBoardAndImages` mutations - the only thing we cannot do directly is on `deleteBoardAndImages`, update the `No Board` board. we'd need to insert image dtos that we may not have loaded. instead, i am just invalidating the tags for that `listImages` cache. so when you `deleteBoardAndImages`, the `No Board` will re-fetch the initial image limit. i think this is more efficient than e.g. fetching all image dtos to insert then inserting them. - handle image usage for `deleteBoardAndImages` - update all (i think/hope) the little bits and pieces in the UI to accomodate these changes * fix(ui): fix board selection logic * feat(ui): add delete board modal loading state * fix(ui): use thumbnails for board cover images * fix(ui): fix race condition with board selection when selecting a board that doesn't have any images loaded, we need to wait until the images haveloaded before selecting the first image. this logic is debounced to ~1000ms. * feat(ui): name 'No Board' correctly, change icon * fix(ui): do not cache listAllImageNames query if we cache it, we can end up with stale image usage during deletion. we could of course manually update the cache as we are doing elsewhere. but because this is a relatively infrequent network request, i'd like to trade increased cache mgmt complexity here for increased resource usage. * feat(ui): reduce drag preview opacity, remove border * fix(ui): fix incorrect queryArg used in `deleteImage` and `updateImage` cache updates * fix(ui): fix doubled open in new tab * fix(ui): fix new generations not getting added to 'No Board' * fix(ui): fix board id not changing on new image when autosave enabled * fix(ui): context menu when selection is 0 need to revise how context menu is triggered later, when we approach multi select * fix(ui): fix deleting does not update counts for all images and all assets * fix(ui): fix all assets board name in boards list collapse button * fix(ui): ensure we never go under 0 for total board count * fix(ui): fix text overflow on board names --------- Co-authored-by: Mary Hipp <maryhipp@Marys-MacBook-Air.local>
2023-07-19 16:06:38 +00:00
};
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
/** DeleteImagesFromListResult */
DeleteImagesFromListResult: {
/** Deleted Images */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
deleted_images: string[];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
};
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Denoise Latents
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* @description Denoises noisy latents to decodable images
*/
DenoiseLatentsInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Noise
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Noise tensor
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
noise?: components["schemas"]["LatentsField"];
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Steps
* @description Number of steps to run
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* @default 10
*/
steps?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* CFG Scale
* @description Classifier-Free Guidance scale
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* @default 7.5
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
cfg_scale?: number | number[];
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Denoising Start
* @description When to start denoising, expressed a percentage of total steps
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* @default 0
*/
denoising_start?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Denoising End
* @description When to stop denoising, expressed a percentage of total steps
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* @default 1
*/
denoising_end?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Scheduler
* @description Scheduler to use during inference
* @default euler
chore(ui): regen types
2023-08-16 01:59:19 +00:00
* @enum {string}
*/
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";
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Control
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description ControlNet(s) to apply
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
control?: components["schemas"]["ControlField"] | components["schemas"]["ControlField"][];
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Latents
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Latents tensor
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
latents?: components["schemas"]["LatentsField"];
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
/**
chore: Regen schema
2023-08-29 00:20:55 +00:00
* Denoise Mask
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description The mask to use for the operation
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
*/
chore: Regen schema
2023-08-29 00:20:55 +00:00
denoise_mask?: components["schemas"]["DenoiseMaskField"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default denoise_latents
* @enum {string}
*/
type: "denoise_latents";
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Positive Conditioning
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Positive conditioning tensor
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
positive_conditioning?: components["schemas"]["ConditioningField"];
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Negative Conditioning
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Negative conditioning tensor
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
negative_conditioning?: components["schemas"]["ConditioningField"];
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* UNet
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description UNet (scheduler, LoRAs)
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
unet?: components["schemas"]["UNetField"];
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
};
chore: Regen schema
2023-08-29 00:20:55 +00:00
/**
* DenoiseMaskField
* @description An inpaint mask field
*/
DenoiseMaskField: {
/**
* Mask Name
* @description The name of the mask image
*/
mask_name: string;
/**
* Masked Latents Name
* @description The name of the masked image latents
*/
masked_latents_name?: string;
};
/**
* DenoiseMaskOutput
* @description Base class for nodes that output a single image
*/
DenoiseMaskOutput: {
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Denoise Mask
* @description Mask for denoise model run
*/
denoise_mask: components["schemas"]["DenoiseMaskField"];
chore: Regen schema
2023-08-29 00:20:55 +00:00
/**
* Type
* @default denoise_mask_output
* @enum {string}
*/
type: "denoise_mask_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(ui): typegen
2023-08-22 05:15:00 +00:00
* Divide Integers
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default div
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +00:00
* 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
* @description Parses a prompt using adieyal/dynamicprompts' random or combinatorial generator
*/
DynamicPromptInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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
*/
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
prompt?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default dynamic_prompt
* @enum {string}
*/
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(ui): regen types
2023-07-17 11:08:53 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Upscale (RealESRGAN)
chore(ui): regen types
2023-07-17 11:08:53 +00:00
* @description Upscales an image using RealESRGAN.
*/
ESRGANInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
chore(ui): regen types
2023-07-17 11:08:53 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
chore(ui): regen types
2023-07-17 11:08:53 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
chore(ui): regen types
2023-07-17 11:08:53 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Image
chore(ui): regen types
2023-07-17 11:08:53 +00:00
* @description The input image
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
image?: components["schemas"]["ImageField"];
chore(ui): regen types
2023-07-17 11:08:53 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Model Name
* @description The Real-ESRGAN model to use
* @default RealESRGAN_x4plus.pth
chore(ui): regen types
2023-07-17 11:08:53 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_name?: "RealESRGAN_x4plus.pth" | "RealESRGAN_x4plus_anime_6B.pth" | "ESRGAN_SRx4_DF2KOST_official-ff704c30.pth" | "RealESRGAN_x2plus.pth";
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default esrgan
* @enum {string}
*/
type: "esrgan";
chore(ui): regen types
2023-07-17 11:08:53 +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
/** Edge */
Edge: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
};
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
/**
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* Float Collection Primitive
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
* @description A collection of float primitive values
*/
FloatCollectionInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Collection
* @description The collection of float values
*/
collection?: number[];
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default float_collection
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
type: "float_collection";
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* FloatCollectionOutput
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description Base class for nodes that output a collection of floats
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
FloatCollectionOutput: {
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Collection
* @description The float collection
*/
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(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default float_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}
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19:36 +00:00
type: "float_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
};
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Float Primitive
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description A float primitive value
*/
FloatInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Value
* @description The float value
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @default 0
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19:36 +00:00
value?: number;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default float
* @enum {string}
*/
type: "float";
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* 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
* @description Creates a range
*/
FloatLinearRangeInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default float_range
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +00:00
* FloatOutput
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description Base class for nodes that output a single 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
*/
FloatOutput: {
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Value
* @description The output float
*/
value: 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(ui): typegen
2023-08-22 05:15:00 +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}
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19: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
};
/** Graph */
Graph: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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: typegen
2023-09-02 01:36:07 +00:00
[key: string]: components["schemas"]["BooleanInvocation"] | components["schemas"]["BooleanCollectionInvocation"] | components["schemas"]["IntegerInvocation"] | components["schemas"]["IntegerCollectionInvocation"] | components["schemas"]["FloatInvocation"] | components["schemas"]["FloatCollectionInvocation"] | components["schemas"]["StringInvocation"] | components["schemas"]["StringCollectionInvocation"] | components["schemas"]["ImageInvocation"] | components["schemas"]["ImageCollectionInvocation"] | components["schemas"]["LatentsInvocation"] | components["schemas"]["LatentsCollectionInvocation"] | components["schemas"]["ColorInvocation"] | components["schemas"]["ConditioningInvocation"] | components["schemas"]["ConditioningCollectionInvocation"] | components["schemas"]["ControlNetInvocation"] | components["schemas"]["ImageProcessorInvocation"] | components["schemas"]["MainModelLoaderInvocation"] | components["schemas"]["LoraLoaderInvocation"] | components["schemas"]["SDXLLoraLoaderInvocation"] | components["schemas"]["VaeLoaderInvocation"] | components["schemas"]["SeamlessModeInvocation"] | components["schemas"]["MetadataAccumulatorInvocation"] | components["schemas"]["SDXLModelLoaderInvocation"] | components["schemas"]["SDXLRefinerModelLoaderInvocation"] | components["schemas"]["CompelInvocation"] | components["schemas"]["SDXLCompelPromptInvocation"] | components["schemas"]["SDXLRefinerCompelPromptInvocation"] | components["schemas"]["ClipSkipInvocation"] | components["schemas"]["SchedulerInvocation"] | components["schemas"]["CreateDenoiseMaskInvocation"] | components["schemas"]["DenoiseLatentsInvocation"] | components["schemas"]["LatentsToImageInvocation"] | components["schemas"]["ResizeLatentsInvocation"] | components["schemas"]["ScaleLatentsInvocation"] | components["schemas"]["ImageToLatentsInvocation"] | components["schemas"]["BlendLatentsInvocation"] | components["schemas"]["ONNXPromptInvocation"] | components["schemas"]["ONNXTextToLatentsInvocation"] | components["schemas"]["ONNXLatentsToImageInvocation"] | components["schemas"]["OnnxModelLoaderInvocation"] | components["schemas"]["ShowImageInvocation"] | components["schemas"]["BlankImageInvocation"] | 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"] | components["schemas"]["ImageNSFWBlurInvocation"] | components["schemas"]["ImageWatermarkInvocation"] | components["schemas"]["MaskEdgeInvocation"] | components["schemas"]["MaskCombineInvocation"] | components["schemas"]["ColorCorrectInvocation"] | components["schemas"]["ImageHueAdjustmentInvocation"] | components["schemas"]["ImageLuminosityAdjustmentInvocation"] | components["schemas"]["ImageSaturationAdjustmentInvocation"] | components["schemas"]["DynamicPromptInvocation"] | components["schemas"]["PromptsFromFileInvocation"] | components["schemas"]["CvInpaintInvocation"] | components["schemas"]["FloatLinearRangeInvocation"] | components["schemas"]["StepParamEasingInvocation"] | components["schemas"]["AddInvocation"] | components["schemas"]["SubtractInvocation"] | components["schemas"]["MultiplyInvocation"] | components["schemas"]["DivideInvocation"] | components["schemas"]["RandomIntInvocation"] | components["schemas"]["NoiseInvocation"] | components["schemas"]["RangeInvocation"] | components["schemas"]["RangeOfSizeInvocation"] | components["schemas"]["RandomRangeInvocation"] | components["schemas"]["ESRGANInvocation"] | components["schemas"]["InfillColorInvocation"] | components["schemas"]["InfillTileInvocation"] | components["schemas"]["InfillPatchMatchInvocation"] | components["schemas"]["LaMaInfillInvocation"] | compone
chore(ui): regen types
2023-08-16 01:59:19 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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: typegen
2023-09-02 01:36:07 +00:00
[key: string]: components["schemas"]["BooleanOutput"] | components["schemas"]["BooleanCollectionOutput"] | components["schemas"]["IntegerOutput"] | components["schemas"]["IntegerCollectionOutput"] | components["schemas"]["FloatOutput"] | components["schemas"]["FloatCollectionOutput"] | components["schemas"]["StringOutput"] | components["schemas"]["StringCollectionOutput"] | components["schemas"]["ImageOutput"] | components["schemas"]["ImageCollectionOutput"] | components["schemas"]["DenoiseMaskOutput"] | components["schemas"]["LatentsOutput"] | components["schemas"]["LatentsCollectionOutput"] | components["schemas"]["ColorOutput"] | components["schemas"]["ColorCollectionOutput"] | components["schemas"]["ConditioningOutput"] | components["schemas"]["ConditioningCollectionOutput"] | components["schemas"]["ControlOutput"] | components["schemas"]["ModelLoaderOutput"] | components["schemas"]["LoraLoaderOutput"] | components["schemas"]["SDXLLoraLoaderOutput"] | components["schemas"]["VaeLoaderOutput"] | components["schemas"]["SeamlessModeOutput"] | components["schemas"]["MetadataAccumulatorOutput"] | components["schemas"]["SDXLModelLoaderOutput"] | components["schemas"]["SDXLRefinerModelLoaderOutput"] | components["schemas"]["ClipSkipInvocationOutput"] | components["schemas"]["SchedulerOutput"] | components["schemas"]["ONNXModelLoaderOutput"] | components["schemas"]["NoiseOutput"] | components["schemas"]["GraphInvocationOutput"] | components["schemas"]["IterateInvocationOutput"] | components["schemas"]["CollectInvocationOutput"];
chore(ui): regen types
2023-08-16 01:59:19 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +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: {
chore(ui): typegen
2023-08-22 05:15:00 +00:00
[key: string]: 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(ui): typegen
2023-08-22 05:15:00 +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: {
chore(ui): typegen
2023-08-22 05:15:00 +00:00
[key: string]: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +00:00
[key: string]: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Graph
* @description The graph to run
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* GraphInvocationOutput
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Base class for all invocation outputs.
*
* All invocation outputs must use the `@invocation_output` decorator to provide their unique 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
*/
GraphInvocationOutput: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* HED (softedge) 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
* @description Applies HED edge detection to image
*/
HedImageProcessorInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Image
* @description The image to process
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Detect Resolution
* @description 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Image Resolution
* @description Pixel resolution for 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Scribble
* @description Whether or not 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Blur 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 Blurs an image
*/
ImageBlurInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +00:00
blur_type?: "gaussian" | "box";
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default img_blur
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Extract Image Channel
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +00:00
channel?: "A" | "R" | "G" | "B";
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default img_chan
* @enum {string}
*/
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
};
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(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* Image Collection Primitive
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
* @description A collection of image primitive values
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
*/
ImageCollectionInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
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
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Collection
* @description The collection of image values
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(ui): typegen
2023-08-22 05:15:00 +00:00
collection?: components["schemas"]["ImageField"][];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default image_collection
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +00:00
* ImageCollectionOutput
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description Base class for nodes that output a collection of 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
*/
ImageCollectionOutput: {
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Collection
* @description The output images
*/
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
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default image_collection_output
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}
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19:36 +00:00
type: "image_collection_output";
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(ui): typegen
2023-08-22 05:15:00 +00:00
* Convert Image 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
* @description Converts an image to a different mode.
*/
ImageConvertInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +00:00
mode?: "L" | "RGB" | "RGBA" | "CMYK" | "YCbCr" | "LAB" | "HSV" | "I" | "F";
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default img_conv
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +00:00
* Crop 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 Crops an image to a specified box. The box can be outside of the image.
*/
ImageCropInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default img_crop
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Starred
rename pin to star, add multiselect and remove single image update api
2023-08-15 16:55:28 +00:00
* @description Whether this image is starred.
(ui) hook up toggle pin mutation with context menu for single image
2023-08-11 15:50:54 +00:00
*/
rename pin to star, add multiselect and remove single image update api
2023-08-15 16:55:28 +00:00
starred: boolean;
(ui) hook up toggle pin mutation with context menu for single image
2023-08-11 15:50:54 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* ImageField
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description An image primitive 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
*/
ImageField: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +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;
};
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
/**
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* Adjust Image Hue
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
* @description Adjusts the Hue of an image.
*/
ImageHueAdjustmentInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Image
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
* @description The image to adjust
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
image?: components["schemas"]["ImageField"];
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Hue
* @description The degrees by which to rotate the hue, 0-360
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
* @default 0
*/
hue?: number;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default img_hue_adjust
* @enum {string}
*/
type: "img_hue_adjust";
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Inverse Lerp 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 Inverse linear interpolation of all pixels of an image
*/
ImageInverseLerpInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default img_ilerp
* @enum {string}
*/
type: "img_ilerp";
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Image Primitive
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description An image primitive value
*/
ImageInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Image
* @description The image to load
*/
image?: components["schemas"]["ImageField"];
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default image
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
type: "image";
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Lerp 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 Linear interpolation of all pixels of an image
*/
ImageLerpInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default img_lerp
* @enum {string}
*/
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
};
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
/**
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* Adjust Image Luminosity
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
* @description Adjusts the Luminosity (Value) of an image.
*/
ImageLuminosityAdjustmentInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Image
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
* @description The image to adjust
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
image?: components["schemas"]["ImageField"];
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Luminosity
* @description The factor by which to adjust the luminosity (value)
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
* @default 1
*/
luminosity?: number;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default img_luminosity_adjust
* @enum {string}
*/
type: "img_luminosity_adjust";
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* ImageMetadata
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description An image's generation 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
*/
ImageMetadata: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Metadata
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The image's core metadata, if it was created in the Linear or Canvas UI
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
chore(ui): regen types
2023-07-12 15:15:09 +00:00
metadata?: Record<string, never>;
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Graph
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The graph that created 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
*/
chore(ui): regen types
2023-07-12 15:15:09 +00:00
graph?: Record<string, never>;
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Multiply 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 Multiplies two images together using `PIL.ImageChops.multiply()`.
*/
ImageMultiplyInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +00:00
image2?: components["schemas"]["ImageField"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default img_mul
* @enum {string}
*/
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
};
add safetychecker and watermark nodes
2023-07-23 20:24:34 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Blur NSFW Image
add safetychecker and watermark nodes
2023-07-23 20:24:34 +00:00
* @description Add blur to NSFW-flagged images
*/
rebuild schema
2023-07-24 12:25:39 +00:00
ImageNSFWBlurInvocation: {
add safetychecker and watermark nodes
2023-07-23 20:24:34 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
add safetychecker and watermark nodes
2023-07-23 20:24:34 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
add safetychecker and watermark nodes
2023-07-23 20:24:34 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Metadata
* @description Optional core metadata to be written to image
*/
metadata?: components["schemas"]["CoreMetadata"];
add safetychecker and watermark nodes
2023-07-23 20:24:34 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default img_nsfw
add safetychecker and watermark nodes
2023-07-23 20:24:34 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
type: "img_nsfw";
add safetychecker and watermark nodes
2023-07-23 20:24:34 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Image
rebuild schema
2023-07-24 12:25:39 +00:00
* @description The image to check
add safetychecker and watermark nodes
2023-07-23 20:24:34 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
image?: components["schemas"]["ImageField"];
add safetychecker and watermark nodes
2023-07-23 20:24:34 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* ImageOutput
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description Base class for nodes that output a single 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
*/
ImageOutput: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default image_output
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +00:00
* Paste 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 Pastes an image into another image.
*/
ImagePasteInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default img_paste
* @enum {string}
*/
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
};
/**
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* Base 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
* @description Base class for invocations that preprocess images for ControlNet
*/
ImageProcessorInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Image
* @description The image to process
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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
rename pin to star, add multiselect and remove single image update api
2023-08-15 16:55:28 +00:00
* - `starred`: change whether the image is starred
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
ImageRecordChanges: {
/** @description The image's new category. */
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
(ui) hook up toggle pin mutation with context menu for single image
2023-08-11 15:50:54 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Starred
rename pin to star, add multiselect and remove single image update api
2023-08-15 16:55:28 +00:00
* @description The image's new `starred` state
(ui) hook up toggle pin mutation with context menu for single image
2023-08-11 15:50:54 +00:00
*/
rename pin to star, add multiselect and remove single image update api
2023-08-15 16:55:28 +00:00
starred?: 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Resize 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 Resizes an image to specific dimensions
*/
ImageResizeInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Width
* @description The width to resize to (px)
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @default 512
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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): fix controlNet models - update controlnet state to use object format for model - update model-parsing helper functions to log errors - update nodes components, types and state - remove controlnets from state when models are loaded and the controlnet's model is not available
2023-07-15 02:19:24 +00:00
width?: 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Height
* @description The height to resize to (px)
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @default 512
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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): fix controlNet models - update controlnet state to use object format for model - update model-parsing helper functions to log errors - update nodes components, types and state - remove controlnets from state when models are loaded and the controlnet's model is not available
2023-07-15 02:19:24 +00:00
height?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +00:00
resample_mode?: "nearest" | "box" | "bilinear" | "hamming" | "bicubic" | "lanczos";
chore: Regen schema
2023-08-29 00:20:55 +00:00
/**
* Metadata
* @description Optional core metadata to be written to image
*/
metadata?: components["schemas"]["CoreMetadata"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default img_resize
* @enum {string}
*/
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
};
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
/**
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* Adjust Image Saturation
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
* @description Adjusts the Saturation of an image.
*/
ImageSaturationAdjustmentInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Image
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
* @description The image to adjust
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
image?: components["schemas"]["ImageField"];
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Saturation
* @description The factor by which to adjust the saturation
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
* @default 1
*/
saturation?: number;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default img_saturation_adjust
* @enum {string}
*/
type: "img_saturation_adjust";
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Scale 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 Scales an image by a factor
*/
ImageScaleInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Scale Factor
* @description The factor by which to scale the image
chore(ui): regen types
2023-07-17 11:08:53 +00:00
* @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
*/
chore(ui): regen types
2023-07-17 11:08:53 +00:00
scale_factor?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +00:00
resample_mode?: "nearest" | "box" | "bilinear" | "hamming" | "bicubic" | "lanczos";
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default img_scale
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +00:00
* Image to 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 Encodes an image into latents.
*/
ImageToLatentsInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Vae
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description 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
*/
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Tiled
* @description Processing using overlapping tiles (reduce 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;
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Fp32
* @description Whether or not to use full float32 precision
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @default false
*/
fp32?: boolean;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default i2l
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
};
rebuild schema
2023-07-24 12:25:39 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Add Invisible Watermark
rebuild schema
2023-07-24 12:25:39 +00:00
* @description Add an invisible watermark to an image
*/
ImageWatermarkInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
rebuild schema
2023-07-24 12:25:39 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
rebuild schema
2023-07-24 12:25:39 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
rebuild schema
2023-07-24 12:25:39 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Image
rebuild schema
2023-07-24 12:25:39 +00:00
* @description The image to check
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
image?: components["schemas"]["ImageField"];
rebuild schema
2023-07-24 12:25:39 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Text
* @description Watermark text
rebuild schema
2023-07-24 12:25:39 +00:00
* @default InvokeAI
*/
text?: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Metadata
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Optional core metadata to be written to image
rebuild schema
2023-07-24 12:25:39 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
metadata?: components["schemas"]["CoreMetadata"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default img_watermark
* @enum {string}
*/
type: "img_watermark";
rebuild schema
2023-07-24 12:25:39 +00:00
};
fix: add response model for star/unstar routes - also implement pessimistic updates for starring, only changing the images that were successfully updated by backend - some autoformat changes crept in
2023-08-16 01:36:43 +00:00
/** ImagesUpdatedFromListResult */
ImagesUpdatedFromListResult: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Updated Image Names
fix: add response model for star/unstar routes - also implement pessimistic updates for starring, only changing the images that were successfully updated by backend - some autoformat changes crept in
2023-08-16 01:36:43 +00:00
* @description The image names that were updated
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
updated_image_names: string[];
fix: add response model for star/unstar routes - also implement pessimistic updates for starring, only changing the images that were successfully updated by backend - some autoformat changes crept in
2023-08-16 01:36:43 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Solid Color 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
* @description Infills transparent areas of an image with a solid color
*/
InfillColorInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +00:00
color?: components["schemas"]["ColorField"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default infill_rgba
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +00:00
* PatchMatch 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
* @description Infills transparent areas of an image using the PatchMatch algorithm
*/
InfillPatchMatchInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Image
* @description The image to infill
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Tile 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
* @description Infills transparent areas of an image with tiles of the image
*/
InfillTileInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default infill_tile
* @enum {string}
*/
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
};
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
/**
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* Integer Collection Primitive
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
* @description A collection of integer primitive values
*/
IntegerCollectionInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Collection
* @description The collection of integer values
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
collection?: number[];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default integer_collection
* @enum {string}
*/
type: "integer_collection";
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* IntegerCollectionOutput
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description Base class for nodes that output a collection of integers
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
IntegerCollectionOutput: {
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Collection
* @description The int collection
*/
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(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default integer_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}
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19:36 +00:00
type: "integer_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(ui): typegen
2023-08-22 05:15:00 +00:00
* Integer Primitive
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description An integer primitive value
*/
IntegerInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Value
* @description The integer value
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @default 0
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19:36 +00:00
value?: number;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default integer
* @enum {string}
*/
type: "integer";
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* IntegerOutput
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description Base class for nodes that output a single integer
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
IntegerOutput: {
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Value
* @description The output integer
*/
value: 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default integer_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}
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19:36 +00:00
type: "integer_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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default iterate
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +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: {
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Collection Item
* @description The item being iterated over
*/
item?: 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(ui): typegen
2023-08-22 05:15:00 +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}
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19: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
};
experimental: LaMa Infill
2023-08-23 19:25:24 +00:00
/**
* LaMa Infill
* @description Infills transparent areas of an image using the LaMa model
*/
LaMaInfillInvocation: {
/**
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
experimental: LaMa Infill
2023-08-23 19:25:24 +00:00
*/
id: string;
/**
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
experimental: LaMa Infill
2023-08-23 19:25:24 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Image
* @description The image to infill
*/
image?: components["schemas"]["ImageField"];
experimental: LaMa Infill
2023-08-23 19:25:24 +00:00
/**
* Type
* @default infill_lama
* @enum {string}
*/
type: "infill_lama";
};
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
/**
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* Latents Collection Primitive
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
* @description A collection of latents tensor primitive values
*/
LatentsCollectionInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Collection
* @description The collection of latents tensors
*/
collection?: components["schemas"]["LatentsField"][];
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default latents_collection
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
type: "latents_collection";
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
};
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* LatentsCollectionOutput
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description Base class for nodes that output a collection of latents tensors
*/
LatentsCollectionOutput: {
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Collection
* @description Latents tensor
*/
collection: components["schemas"]["LatentsField"][];
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default latents_collection_output
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @enum {string}
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19:36 +00:00
type: "latents_collection_output";
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* LatentsField
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description A latents tensor primitive 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
*/
LatentsField: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +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;
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Seed
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* @description Seed used to generate this latents
*/
seed?: 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
};
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Latents Primitive
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description A latents tensor primitive value
*/
LatentsInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Latents
* @description The latents tensor
*/
latents?: components["schemas"]["LatentsField"];
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default latents
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
type: "latents";
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* LatentsOutput
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description Base class for nodes that output a single latents tensor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
LatentsOutput: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Latents
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Latents tensor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Width
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Width of output (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
*/
width: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Height
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Height of output (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
*/
height: number;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default latents_output
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +00:00
* Latents 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
* @description Generates an image from latents.
*/
LatentsToImageInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Tiled
* @description Processing using overlapping tiles (reduce 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;
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Fp32
* @description Whether or not to use full float32 precision
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @default false
*/
fp32?: boolean;
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Metadata
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Optional core metadata to be written to image
chore(ui): regen types
2023-07-12 15:15:09 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
metadata?: components["schemas"]["CoreMetadata"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default l2i
* @enum {string}
*/
type: "l2i";
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Latents
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Latents tensor
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
latents?: components["schemas"]["LatentsField"];
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Vae
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description VAE
*/
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Leres (Depth) Processor
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* @description Applies leres 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: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
LeresImageProcessorInvocation: {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Image
* @description The image to process
*/
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(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default leres_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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Detect Resolution
* @description 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Image Resolution
* @description Pixel resolution for 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Lineart Anime 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
* @description Applies line art anime processing to image
*/
LineartAnimeImageProcessorInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Image
* @description The image to process
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Detect Resolution
* @description 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Image Resolution
* @description Pixel resolution for 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Lineart 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
* @description Applies line art processing to image
*/
LineartImageProcessorInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Image
* @description The image to process
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Detect Resolution
* @description 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Image Resolution
* @description Pixel resolution for 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(ui): typegen
2023-08-22 05:15:00 +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;
};
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* LoRAMetadataField
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description LoRA metadata for an image generated in InvokeAI.
*/
LoRAMetadataField: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Lora
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The LoRA model
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
lora: components["schemas"]["LoRAModelField"];
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Weight
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The weight of the LoRA model
*/
weight: 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
/** LoRAModelConfig */
LoRAModelConfig: {
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/** Model Name */
model_name: string;
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-07-04 11:12:49 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* LoRAModelField
chore(ui): regen types
2023-07-04 11:12:49 +00:00
* @description LoRA model field
*/
LoRAModelField: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Model Name
chore(ui): regen types
2023-07-04 11:12:49 +00:00
* @description Name of the LoRA model
*/
model_name: string;
/** @description Base model */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
base_model: components["schemas"]["BaseModelType"];
chore(ui): regen types
2023-07-04 11:12:49 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +00:00
LoRAModelFormat: "lycoris" | "diffusers";
merge with main
2023-07-20 15:45:54 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* LogLevel
* @description An enumeration.
merge with main
2023-07-20 15:45:54 +00:00
* @enum {integer}
*/
LogLevel: 0 | 10 | 20 | 30 | 40 | 50;
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* 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
* @description Apply selected lora to unet and text_encoder.
*/
LoraLoaderInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +00:00
* LoRA
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description LoRA model to load
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
lora: components["schemas"]["LoRAModelField"];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Weight
* @description The weight at which the LoRA is applied to each 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
* @default 0.75
*/
weight?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* UNet
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description UNet (scheduler, 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
*/
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* CLIP
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description CLIP (tokenizer, text encoder, LoRAs) and skipped layer 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
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
clip?: components["schemas"]["ClipField"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default lora_loader
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* UNet
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description UNet (scheduler, 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
*/
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* CLIP
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description CLIP (tokenizer, text encoder, LoRAs) and skipped layer 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
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
clip?: components["schemas"]["ClipField"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default lora_loader_output
* @enum {string}
*/
type: "lora_loader_output";
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* MainModelField
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* @description Main model field
*/
MainModelField: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Model Name
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* @description Name of the model
*/
model_name: string;
/** @description Base model */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
base_model: components["schemas"]["BaseModelType"];
Add model_type to the model state object
2023-07-19 02:40:27 +00:00
/** @description Model Type */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_type: components["schemas"]["ModelType"];
Add model_type to the model state object
2023-07-19 02:40:27 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Main Model
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* @description Loads a main model, outputting its submodels.
*/
MainModelLoaderInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Model
* @description Main model (UNet, VAE, CLIP) to load
*/
model: components["schemas"]["MainModelField"];
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default main_model_loader
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
type: "main_model_loader";
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
};
wip: Port Outpainting to new backend
2023-08-11 18:15:59 +00:00
/**
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* Combine Masks
wip: Port Outpainting to new backend
2023-08-11 18:15:59 +00:00
* @description Combine two masks together by multiplying them using `PIL.ImageChops.multiply()`.
*/
MaskCombineInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
wip: Port Outpainting to new backend
2023-08-11 18:15:59 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
wip: Port Outpainting to new backend
2023-08-11 18:15:59 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
wip: Port Outpainting to new backend
2023-08-11 18:15:59 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Mask1
wip: Port Outpainting to new backend
2023-08-11 18:15:59 +00:00
* @description The first mask to combine
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
mask1?: components["schemas"]["ImageField"];
wip: Port Outpainting to new backend
2023-08-11 18:15:59 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Mask2
wip: Port Outpainting to new backend
2023-08-11 18:15:59 +00:00
* @description The second image to combine
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
mask2?: components["schemas"]["ImageField"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default mask_combine
* @enum {string}
*/
type: "mask_combine";
wip: Port Outpainting to new backend
2023-08-11 18:15:59 +00:00
};
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Mask Edge
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* @description Applies an edge mask to an image
*/
MaskEdgeInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Image
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* @description The image to apply the mask to
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
image?: components["schemas"]["ImageField"];
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Edge Size
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* @description The size of the edge
*/
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
edge_size?: number;
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Edge Blur
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* @description The amount of blur on the edge
*/
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
edge_blur?: number;
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Low Threshold
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* @description First threshold for the hysteresis procedure in Canny edge detection
*/
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
low_threshold?: number;
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* High Threshold
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
* @description Second threshold for the hysteresis procedure in Canny edge detection
*/
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
high_threshold?: number;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default mask_edge
* @enum {string}
*/
type: "mask_edge";
feat: Update LinearUI to use new backend (except Inpaint)
2023-08-11 10:22:01 +00:00
};
chore: Change PipelineModels to MainModels
2023-06-28 20:13:36 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Mask from Alpha
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default tomask
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +00:00
* 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
* @description Applies mediapipe face processing to image
*/
MediapipeFaceProcessorInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Image
* @description The image to process
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
};
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* MergeInterpolationMethod
* @description An enumeration.
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
MergeInterpolationMethod: "weighted_sum" | "sigmoid" | "inv_sigmoid" | "add_difference";
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Metadata Accumulator
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description Outputs a Core Metadata Object
*/
MetadataAccumulatorInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
chore(ui): regen types
2023-07-12 15:15:09 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Generation Mode
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The generation mode that output this image
*/
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
generation_mode?: string;
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Positive Prompt
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The positive prompt parameter
*/
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
positive_prompt?: string;
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Negative Prompt
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The negative prompt parameter
*/
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
negative_prompt?: string;
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Width
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The width parameter
*/
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
width?: number;
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Height
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The height parameter
*/
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
height?: number;
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Seed
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The seed used for noise generation
*/
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
seed?: number;
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Rand Device
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The device used for random number generation
*/
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
rand_device?: string;
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Cfg Scale
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The classifier-free guidance scale parameter
*/
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
cfg_scale?: number;
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Steps
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The number of steps used for inference
*/
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
steps?: number;
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Scheduler
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The scheduler used for inference
*/
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
scheduler?: string;
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Clip Skip
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The number of skipped CLIP layers
*/
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
clip_skip?: number;
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Model
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The main model used for inference
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model?: components["schemas"]["MainModelField"];
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Controlnets
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The ControlNets used for inference
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
controlnets?: components["schemas"]["ControlField"][];
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Loras
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The LoRAs used for inference
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
loras?: components["schemas"]["LoRAMetadataField"][];
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Strength
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The strength used for latents-to-latents
*/
strength?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Init Image
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The name of the initial image
*/
init_image?: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Vae
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The VAE used for decoding, if the main model's default was not used
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
vae?: components["schemas"]["VAEModelField"];
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Positive Style Prompt
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
* @description The positive style prompt parameter
*/
positive_style_prompt?: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Negative Style Prompt
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
* @description The negative style prompt parameter
*/
negative_style_prompt?: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Refiner Model
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
* @description The SDXL Refiner model used
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
refiner_model?: components["schemas"]["MainModelField"];
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Refiner Cfg Scale
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
* @description The classifier-free guidance scale parameter used for the refiner
*/
refiner_cfg_scale?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Refiner Steps
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
* @description The number of steps used for the refiner
*/
refiner_steps?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Refiner Scheduler
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
* @description The scheduler used for the refiner
*/
refiner_scheduler?: string;
/**
chore: typegen
2023-09-02 01:36:07 +00:00
* Refiner Positive Aesthetic Score
feat: Add SDXL Negative Aesthetic Score
2023-08-13 16:02:36 +00:00
* @description The aesthetic score used for the refiner
*/
chore: typegen
2023-09-02 01:36:07 +00:00
refiner_positive_aesthetic_score?: number;
feat: Add SDXL Negative Aesthetic Score
2023-08-13 16:02:36 +00:00
/**
chore: typegen
2023-09-02 01:36:07 +00:00
* Refiner Negative Aesthetic Score
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
* @description The aesthetic score used for the refiner
*/
chore: typegen
2023-09-02 01:36:07 +00:00
refiner_negative_aesthetic_score?: number;
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Refiner Start
feat: sdxl metadata - update `CoreMetadata` class & `MetadataAccumulator` with fields for SDXL-specific metadata - update the linear UI graphs to populate this metadata
2023-07-25 14:22:47 +00:00
* @description The start value used for refiner denoising
*/
refiner_start?: number;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default metadata_accumulator
* @enum {string}
*/
type: "metadata_accumulator";
chore(ui): regen types
2023-07-12 15:15:09 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* MetadataAccumulatorOutput
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description The output of the MetadataAccumulator node
*/
MetadataAccumulatorOutput: {
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Metadata
* @description The core metadata for the image
*/
metadata: components["schemas"]["CoreMetadata"];
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default metadata_accumulator_output
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @enum {string}
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19:36 +00:00
type: "metadata_accumulator_output";
chore(ui): regen types
2023-07-12 15:15:09 +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
/**
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* Midas Depth 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
* @description Applies Midas depth processing to image
*/
MidasDepthImageProcessorInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Image
* @description The image to process
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* MLSD 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
* @description Applies MLSD processing to image
*/
MlsdImageProcessorInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Image
* @description The image to process
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Detect Resolution
* @description 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Image Resolution
* @description Pixel resolution for 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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* UNet
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description UNet (scheduler, 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
*/
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* CLIP
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description CLIP (tokenizer, text encoder, LoRAs) and skipped layer 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
*/
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* VAE
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description 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
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
vae: components["schemas"]["VaeField"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default model_loader_output
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +00:00
ModelType: "onnx" | "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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +00:00
models: (components["schemas"]["ONNXStableDiffusion1ModelConfig"] | components["schemas"]["StableDiffusion1ModelCheckpointConfig"] | components["schemas"]["StableDiffusion1ModelDiffusersConfig"] | components["schemas"]["VaeModelConfig"] | components["schemas"]["LoRAModelConfig"] | components["schemas"]["ControlNetModelCheckpointConfig"] | components["schemas"]["ControlNetModelDiffusersConfig"] | components["schemas"]["TextualInversionModelConfig"] | components["schemas"]["ONNXStableDiffusion2ModelConfig"] | components["schemas"]["StableDiffusion2ModelCheckpointConfig"] | components["schemas"]["StableDiffusion2ModelDiffusersConfig"] | components["schemas"]["StableDiffusionXLModelCheckpointConfig"] | components["schemas"]["StableDiffusionXLModelDiffusersConfig"])[];
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Multiply Integers
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default mul
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +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 Generates latent noise.
*/
NoiseInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Seed
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Seed for random number generation
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
seed?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Width
* @description Width of output (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 512
*/
width?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Height
* @description Height of output (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 512
*/
height?: number;
chore(ui): regen types
2023-06-27 03:57:41 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +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(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default noise
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Noise
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Noise tensor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Width
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Width of output (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
*/
width: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Height
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Height of output (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
*/
height: number;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default noise_output
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +00:00
* Normal BAE 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
* @description Applies NormalBae processing to image
*/
NormalbaeImageProcessorInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Image
* @description The image to process
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Detect Resolution
* @description 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Image Resolution
* @description Pixel resolution for 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;
};
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* ONNX Latents to Image
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
* @description Generates an image from latents.
*/
ONNXLatentsToImageInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Latents
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Denoised latents tensor
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
latents?: components["schemas"]["LatentsField"];
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Vae
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description VAE
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
vae?: components["schemas"]["VaeField"];
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Metadata
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Optional core metadata to be written to image
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
metadata?: components["schemas"]["CoreMetadata"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default l2i_onnx
* @enum {string}
*/
type: "l2i_onnx";
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* ONNXModelLoaderOutput
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
* @description Model loader output
*/
ONNXModelLoaderOutput: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* UNet
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description UNet (scheduler, LoRAs)
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
unet?: components["schemas"]["UNetField"];
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* CLIP
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description CLIP (tokenizer, text encoder, LoRAs) and skipped layer count
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
clip?: components["schemas"]["ClipField"];
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* VAE Decoder
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description VAE
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
vae_decoder?: components["schemas"]["VaeField"];
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* VAE Encoder
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description VAE
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
vae_encoder?: components["schemas"]["VaeField"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default model_loader_output_onnx
* @enum {string}
*/
type: "model_loader_output_onnx";
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* ONNX Prompt (Raw)
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
* @description A node to process inputs and produce outputs.
* May use dependency injection in __init__ to receive providers.
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
*
* All invocations must use the `@invocation` decorator to provide their unique type.
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
*/
ONNXPromptInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Prompt
* @description Raw prompt text (no parsing)
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
* @default
*/
prompt?: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Clip
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description CLIP (tokenizer, text encoder, LoRAs) and skipped layer count
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
clip?: components["schemas"]["ClipField"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default prompt_onnx
* @enum {string}
*/
type: "prompt_onnx";
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
};
/** ONNXStableDiffusion1ModelConfig */
ONNXStableDiffusion1ModelConfig: {
/** Model Name */
model_name: string;
chore(ui): regen types
2023-08-16 01:59:19 +00:00
base_model: components["schemas"]["BaseModelType"];
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Model Type
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_type: "onnx";
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/** Path */
path: string;
/** Description */
description?: string;
Fix issues caused by merge
2023-07-28 18:00:32 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Model Format
Fix issues caused by merge
2023-07-28 18:00:32 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_format: "onnx";
error?: components["schemas"]["ModelError"];
variant: components["schemas"]["ModelVariantType"];
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
};
/** ONNXStableDiffusion2ModelConfig */
ONNXStableDiffusion2ModelConfig: {
/** Model Name */
model_name: string;
chore(ui): regen types
2023-08-16 01:59:19 +00:00
base_model: components["schemas"]["BaseModelType"];
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Model Type
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_type: "onnx";
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/** Path */
path: string;
/** Description */
description?: string;
Fix issues caused by merge
2023-07-28 18:00:32 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Model Format
Fix issues caused by merge
2023-07-28 18:00:32 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_format: "onnx";
error?: components["schemas"]["ModelError"];
variant: components["schemas"]["ModelVariantType"];
prediction_type: components["schemas"]["SchedulerPredictionType"];
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/** Upcast Attention */
upcast_attention: boolean;
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* ONNX Text to Latents
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
* @description Generates latents from conditionings.
*/
ONNXTextToLatentsInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Positive Conditioning
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Positive conditioning tensor
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
positive_conditioning?: components["schemas"]["ConditioningField"];
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Negative Conditioning
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Negative conditioning tensor
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
negative_conditioning?: components["schemas"]["ConditioningField"];
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Noise
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Noise tensor
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
noise?: components["schemas"]["LatentsField"];
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Steps
* @description Number of steps to run
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
* @default 10
*/
steps?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Cfg Scale
* @description Classifier-Free Guidance scale
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
* @default 7.5
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
cfg_scale?: number | number[];
chore(ui): regen types
2023-08-16 01:59:19 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Scheduler
* @description Scheduler to use during inference
* @default euler
chore(ui): regen types
2023-08-16 01:59:19 +00:00
* @enum {string}
*/
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";
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Precision
* @description Precision to use
* @default tensor(float16)
chore(ui): regen types
2023-08-16 01:59:19 +00:00
* @enum {string}
*/
precision?: "tensor(bool)" | "tensor(int8)" | "tensor(uint8)" | "tensor(int16)" | "tensor(uint16)" | "tensor(int32)" | "tensor(uint32)" | "tensor(int64)" | "tensor(uint64)" | "tensor(float16)" | "tensor(float)" | "tensor(double)";
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Unet
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description UNet (scheduler, LoRAs)
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
unet?: components["schemas"]["UNetField"];
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Control
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description ControlNet(s) to apply
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
control?: components["schemas"]["ControlField"] | components["schemas"]["ControlField"][];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default t2l_onnx
* @enum {string}
*/
type: "t2l_onnx";
Add onnx models to the model manager UI
2023-07-27 13:37:37 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
};
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* OnnxModelField
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
* @description Onnx model field
*/
OnnxModelField: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Model Name
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
* @description Name of the model
*/
model_name: string;
/** @description Base model */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
base_model: components["schemas"]["BaseModelType"];
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/** @description Model Type */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_type: components["schemas"]["ModelType"];
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* ONNX Main Model
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
* @description Loads a main model, outputting its submodels.
*/
OnnxModelLoaderInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Model
* @description ONNX Main model (UNet, VAE, CLIP) to load
*/
model: components["schemas"]["OnnxModelField"];
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default onnx_model_loader
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
type: "onnx_model_loader";
Add onnx models to the model manager UI
2023-07-27 13:37:37 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Openpose 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
* @description Applies Openpose processing to image
*/
OpenposeImageProcessorInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Image
* @description The image to process
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Detect Resolution
* @description 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Image Resolution
* @description Pixel resolution for 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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* PIDI 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
* @description Applies PIDI processing to image
*/
PidiImageProcessorInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Image
* @description The image to process
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Detect Resolution
* @description 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Image Resolution
* @description Pixel resolution for 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Safe
* @description Whether or not 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Scribble
* @description Whether or not 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;
};
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Prompts from File
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @description Loads prompts from a text file
*/
PromptsFromFileInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* File Path
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @description Path to prompt text file
*/
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
file_path?: string;
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Pre Prompt
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @description String to prepend to each prompt
*/
pre_prompt?: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Post Prompt
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @description String to append to each prompt
*/
post_prompt?: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Start Line
* @description Line in the file to start start from
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @default 1
*/
start_line?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Max Prompts
* @description Max lines to read from file (0=all)
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @default 1
*/
max_prompts?: number;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default prompt_from_file
* @enum {string}
*/
type: "prompt_from_file";
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Random Integer
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default rand_int
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +00:00
* 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
* @description Creates a collection of random numbers
*/
RandomRangeInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default random_range
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +00:00
* Integer 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
* @description Creates a range of numbers from start to stop with step
*/
RangeInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default range
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +00:00
* Integer 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
* @description Creates a range from start to start + size with step
*/
RangeOfSizeInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default range_of_size
* @enum {string}
*/
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
};
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
/** RemoveImagesFromBoardResult */
RemoveImagesFromBoardResult: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Removed Image Names
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
* @description The image names that were removed from their board
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
removed_image_names: string[];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Resize 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 Resizes latents to explicit width/height (in pixels). Provided dimensions are floor-divided by 8.
*/
ResizeLatentsInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Latents
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Latents tensor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Width
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Width of output (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
*/
feat(ui): fix controlNet models - update controlnet state to use object format for model - update model-parsing helper functions to log errors - update nodes components, types and state - remove controlnets from state when models are loaded and the controlnet's model is not available
2023-07-15 02:19:24 +00:00
width?: 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Height
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Width of output (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
*/
feat(ui): fix controlNet models - update controlnet state to use object format for model - update model-parsing helper functions to log errors - update nodes components, types and state - remove controlnets from state when models are loaded and the controlnet's model is not available
2023-07-15 02:19:24 +00:00
height?: 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Mode
* @description 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(ui): regen types
2023-08-16 01:59:19 +00:00
mode?: "nearest" | "linear" | "bilinear" | "bicubic" | "trilinear" | "area" | "nearest-exact";
chore(ui): regen types
2023-07-13 05:22:18 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Antialias
* @description Whether or not to apply antialiasing (bilinear or bicubic 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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default lresize
* @enum {string}
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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
/**
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* SDXL Prompt
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @description Parse prompt using compel package to 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
*/
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
SDXLCompelPromptInvocation: {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Prompt
* @description Prompt to be parsed by Compel to create a conditioning tensor
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @default
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
prompt?: 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Style
* @description Prompt to be parsed by Compel to create a conditioning tensor
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @default
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
style?: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Original Width
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @default 1024
*/
original_width?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Original Height
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @default 1024
*/
original_height?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Crop Top
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @default 0
*/
crop_top?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Crop Left
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @default 0
*/
crop_left?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Target Width
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @default 1024
*/
target_width?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Target Height
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @default 1024
*/
target_height?: number;
/**
feat: polymorphic fields Initial support for polymorphic field types. Polymorphic types are a single of or list of a specific type. For example, `Union[str, list[str]]`. Polymorphics do not yet have support for direct input in the UI (will come in the future). They will be forcibly set as Connection-only fields, in which case users will not be able to provide direct input to the field. If a polymorphic should present as a singleton type - which would allow direct input - the node must provide an explicit type hint. For example, `DenoiseLatents`' `CFG Scale` is polymorphic, but in the node editor, we want to present this as a number input. In the node definition, the field is given `ui_type=UIType.Float`, which tells the UI to treat this as a `float` field. The connection validation logic will prevent connecting a collection to `CFG Scale` in this situation, because it is typed as `float`. The workaround is to disable validation from the settings to make this specific connection. A future improvement will resolve this. This also introduces better support for collection field types. Like polymorphics, collection types are parsed automatically by the client and do not need any specific type hints. Also like polymorphics, there is no support yet for direct input of collection types in the UI. - Disabling validation in workflow editor now displays the visual hints for valid connections, but lets you connect to anything. - Added `ui_order: int` to `InputField` and `OutputField`. The UI will use this, if present, to order fields in a node UI. See usage in `DenoiseLatents` for an example. - Updated the field colors - duplicate colors have just been lightened a bit. It's not perfect but it was a quick fix. - Field handles for collections are the same color as their single counterparts, but have a dark dot in the center of them. - Field handles for polymorphics are a rounded square with dot in the middle. - Removed all fields that just render `null` from `InputFieldRenderer`, replaced with a single fallback - Removed logic in `zValidatedWorkflow`, which checked for existence of node templates for each node in a workflow. This logic introduced a circular dependency, due to importing the global redux `store` in order to get the node templates within a zod schema. It's actually fine to just leave this out entirely; The case of a missing node template is handled by the UI. Fixing it otherwise would introduce a substantial headache. - Fixed the `ControlNetInvocation.control_model` field default, which was a string when it shouldn't have one.
2023-09-01 09:40:27 +00:00
* CLIP 1
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description CLIP (tokenizer, text encoder, LoRAs) and skipped layer count
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
clip?: components["schemas"]["ClipField"];
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
/**
feat: polymorphic fields Initial support for polymorphic field types. Polymorphic types are a single of or list of a specific type. For example, `Union[str, list[str]]`. Polymorphics do not yet have support for direct input in the UI (will come in the future). They will be forcibly set as Connection-only fields, in which case users will not be able to provide direct input to the field. If a polymorphic should present as a singleton type - which would allow direct input - the node must provide an explicit type hint. For example, `DenoiseLatents`' `CFG Scale` is polymorphic, but in the node editor, we want to present this as a number input. In the node definition, the field is given `ui_type=UIType.Float`, which tells the UI to treat this as a `float` field. The connection validation logic will prevent connecting a collection to `CFG Scale` in this situation, because it is typed as `float`. The workaround is to disable validation from the settings to make this specific connection. A future improvement will resolve this. This also introduces better support for collection field types. Like polymorphics, collection types are parsed automatically by the client and do not need any specific type hints. Also like polymorphics, there is no support yet for direct input of collection types in the UI. - Disabling validation in workflow editor now displays the visual hints for valid connections, but lets you connect to anything. - Added `ui_order: int` to `InputField` and `OutputField`. The UI will use this, if present, to order fields in a node UI. See usage in `DenoiseLatents` for an example. - Updated the field colors - duplicate colors have just been lightened a bit. It's not perfect but it was a quick fix. - Field handles for collections are the same color as their single counterparts, but have a dark dot in the center of them. - Field handles for polymorphics are a rounded square with dot in the middle. - Removed all fields that just render `null` from `InputFieldRenderer`, replaced with a single fallback - Removed logic in `zValidatedWorkflow`, which checked for existence of node templates for each node in a workflow. This logic introduced a circular dependency, due to importing the global redux `store` in order to get the node templates within a zod schema. It's actually fine to just leave this out entirely; The case of a missing node template is handled by the UI. Fixing it otherwise would introduce a substantial headache. - Fixed the `ControlNetInvocation.control_model` field default, which was a string when it shouldn't have one.
2023-09-01 09:40:27 +00:00
* CLIP 2
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description CLIP (tokenizer, text encoder, LoRAs) and skipped layer count
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
clip2?: components["schemas"]["ClipField"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default sdxl_compel_prompt
* @enum {string}
*/
type: "sdxl_compel_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
};
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* SDXL LoRA
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
* @description Apply selected lora to unet and text_encoder.
*/
SDXLLoraLoaderInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
workflow?: string;
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* LoRA
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description LoRA model to load
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
lora: components["schemas"]["LoRAModelField"];
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Weight
* @description The weight at which the LoRA is applied to each model
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
* @default 0.75
*/
weight?: number;
/**
feat: polymorphic fields Initial support for polymorphic field types. Polymorphic types are a single of or list of a specific type. For example, `Union[str, list[str]]`. Polymorphics do not yet have support for direct input in the UI (will come in the future). They will be forcibly set as Connection-only fields, in which case users will not be able to provide direct input to the field. If a polymorphic should present as a singleton type - which would allow direct input - the node must provide an explicit type hint. For example, `DenoiseLatents`' `CFG Scale` is polymorphic, but in the node editor, we want to present this as a number input. In the node definition, the field is given `ui_type=UIType.Float`, which tells the UI to treat this as a `float` field. The connection validation logic will prevent connecting a collection to `CFG Scale` in this situation, because it is typed as `float`. The workaround is to disable validation from the settings to make this specific connection. A future improvement will resolve this. This also introduces better support for collection field types. Like polymorphics, collection types are parsed automatically by the client and do not need any specific type hints. Also like polymorphics, there is no support yet for direct input of collection types in the UI. - Disabling validation in workflow editor now displays the visual hints for valid connections, but lets you connect to anything. - Added `ui_order: int` to `InputField` and `OutputField`. The UI will use this, if present, to order fields in a node UI. See usage in `DenoiseLatents` for an example. - Updated the field colors - duplicate colors have just been lightened a bit. It's not perfect but it was a quick fix. - Field handles for collections are the same color as their single counterparts, but have a dark dot in the center of them. - Field handles for polymorphics are a rounded square with dot in the middle. - Removed all fields that just render `null` from `InputFieldRenderer`, replaced with a single fallback - Removed logic in `zValidatedWorkflow`, which checked for existence of node templates for each node in a workflow. This logic introduced a circular dependency, due to importing the global redux `store` in order to get the node templates within a zod schema. It's actually fine to just leave this out entirely; The case of a missing node template is handled by the UI. Fixing it otherwise would introduce a substantial headache. - Fixed the `ControlNetInvocation.control_model` field default, which was a string when it shouldn't have one.
2023-09-01 09:40:27 +00:00
* UNet
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description UNet (scheduler, LoRAs)
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
unet?: components["schemas"]["UNetField"];
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* CLIP 1
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description CLIP (tokenizer, text encoder, LoRAs) and skipped layer count
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
clip?: components["schemas"]["ClipField"];
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* CLIP 2
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description CLIP (tokenizer, text encoder, LoRAs) and skipped layer count
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
clip2?: components["schemas"]["ClipField"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default sdxl_lora_loader
* @enum {string}
*/
type: "sdxl_lora_loader";
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* SDXLLoraLoaderOutput
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description SDXL LoRA Loader Output
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
*/
SDXLLoraLoaderOutput: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* UNet
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description UNet (scheduler, LoRAs)
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
unet?: components["schemas"]["UNetField"];
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* CLIP 1
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description CLIP (tokenizer, text encoder, LoRAs) and skipped layer count
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
clip?: components["schemas"]["ClipField"];
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* CLIP 2
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description CLIP (tokenizer, text encoder, LoRAs) and skipped layer count
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
clip2?: components["schemas"]["ClipField"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default sdxl_lora_loader_output
* @enum {string}
*/
type: "sdxl_lora_loader_output";
feat(ui): add LoRA support to SDXL linear UI new graph modifier `addSDXLLoRasToGraph()` handles adding LoRA to the SDXL t2i and i2i graphs.
2023-08-08 02:00:05 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* SDXL Main Model
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @description Loads an sdxl base model, outputting its submodels.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
SDXLModelLoaderInvocation: {
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(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
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
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Model
* @description SDXL Main model (UNet, VAE, CLIP1, CLIP2) to load
*/
model: components["schemas"]["MainModelField"];
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(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default sdxl_model_loader
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(ui): regen types
2023-08-16 01:59:19 +00:00
type: "sdxl_model_loader";
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(ui): typegen
2023-08-22 05:15:00 +00:00
* SDXLModelLoaderOutput
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @description SDXL base 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
*/
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
SDXLModelLoaderOutput: {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* UNet
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description UNet (scheduler, LoRAs)
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
unet: components["schemas"]["UNetField"];
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* CLIP 1
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description CLIP (tokenizer, text encoder, LoRAs) and skipped layer count
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
clip: components["schemas"]["ClipField"];
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* CLIP 2
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description CLIP (tokenizer, text encoder, LoRAs) and skipped layer count
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
clip2: components["schemas"]["ClipField"];
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* VAE
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description VAE
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
vae: components["schemas"]["VaeField"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default sdxl_model_loader_output
* @enum {string}
*/
type: "sdxl_model_loader_output";
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
};
/**
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* SDXL Refiner Prompt
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @description Parse prompt using compel package to conditioning.
*/
SDXLRefinerCompelPromptInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Style
* @description Prompt to be parsed by Compel to create a conditioning tensor
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @default
*/
style?: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Original Width
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @default 1024
*/
original_width?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Original Height
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @default 1024
*/
original_height?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Crop Top
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @default 0
*/
crop_top?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Crop Left
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @default 0
*/
crop_left?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Aesthetic Score
* @description The aesthetic score to apply to the conditioning tensor
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @default 6
*/
aesthetic_score?: number;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Clip2
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description CLIP (tokenizer, text encoder, LoRAs) and skipped layer count
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
clip2?: components["schemas"]["ClipField"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default sdxl_refiner_compel_prompt
* @enum {string}
*/
type: "sdxl_refiner_compel_prompt";
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* SDXL Refiner Model
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @description Loads an sdxl refiner model, outputting its submodels.
*/
SDXLRefinerModelLoaderInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Model
* @description SDXL Refiner Main Modde (UNet, VAE, CLIP2) to load
*/
model: components["schemas"]["MainModelField"];
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default sdxl_refiner_model_loader
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
type: "sdxl_refiner_model_loader";
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* SDXLRefinerModelLoaderOutput
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @description SDXL refiner model loader output
*/
SDXLRefinerModelLoaderOutput: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* UNet
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description UNet (scheduler, LoRAs)
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
unet: components["schemas"]["UNetField"];
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* CLIP 2
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description CLIP (tokenizer, text encoder, LoRAs) and skipped layer count
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
clip2: components["schemas"]["ClipField"];
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* VAE
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description VAE
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
vae: components["schemas"]["VaeField"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default sdxl_refiner_model_loader_output
* @enum {string}
*/
type: "sdxl_refiner_model_loader_output";
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Scale 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 Scales latents by a given factor.
*/
ScaleLatentsInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Latents
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Latents tensor
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Scale Factor
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description The factor by which to 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
*/
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
scale_factor?: 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Mode
* @description 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(ui): regen types
2023-08-16 01:59:19 +00:00
mode?: "nearest" | "linear" | "bilinear" | "bicubic" | "trilinear" | "area" | "nearest-exact";
chore(ui): regen types
2023-07-13 05:22:18 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Antialias
* @description Whether or not to apply antialiasing (bilinear or bicubic 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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default lscale
* @enum {string}
*/
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: typegen
2023-09-02 01:36:07 +00:00
/**
* Scheduler
* @description Selects a scheduler.
*/
SchedulerInvocation: {
/**
* Id
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
*/
id: string;
/**
* Is Intermediate
* @description Whether or not this is an intermediate invocation.
* @default false
*/
is_intermediate?: boolean;
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
/**
* Scheduler
* @description Scheduler to use during inference
* @default euler
* @enum {string}
*/
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";
/**
* Type
* @default scheduler
* @enum {string}
*/
type: "scheduler";
};
/**
* SchedulerOutput
* @description Base class for all invocation outputs.
*
* All invocation outputs must use the `@invocation_output` decorator to provide their unique type.
*/
SchedulerOutput: {
/**
* Scheduler
* @description Scheduler to use during inference
* @enum {string}
*/
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";
/**
* Type
* @default scheduler_output
* @enum {string}
*/
type: "scheduler_output";
};
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* SchedulerPredictionType
* @description An enumeration.
Add onnx models to the model manager UI
2023-07-27 13:37:37 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
SchedulerPredictionType: "epsilon" | "v_prediction" | "sample";
chore: Regen schema
2023-08-29 00:20:55 +00:00
/**
* Seamless
* @description Applies the seamless transformation to the Model UNet and VAE.
*/
SeamlessModeInvocation: {
/**
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
chore: Regen schema
2023-08-29 00:20:55 +00:00
*/
id: string;
/**
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
chore: Regen schema
2023-08-29 00:20:55 +00:00
* @default false
*/
is_intermediate?: boolean;
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
/**
* UNet
* @description UNet (scheduler, LoRAs)
*/
unet?: components["schemas"]["UNetField"];
/**
* VAE
* @description VAE model to load
*/
vae?: components["schemas"]["VaeField"];
/**
* Seamless Y
* @description Specify whether Y axis is seamless
* @default true
*/
seamless_y?: boolean;
/**
* Seamless X
* @description Specify whether X axis is seamless
* @default true
*/
seamless_x?: boolean;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default seamless
* @enum {string}
*/
type: "seamless";
chore: Regen schema
2023-08-29 00:20:55 +00:00
};
/**
* SeamlessModeOutput
* @description Modified Seamless Model output
*/
SeamlessModeOutput: {
/**
* UNet
* @description UNet (scheduler, LoRAs)
*/
unet?: components["schemas"]["UNetField"];
/**
* VAE
* @description VAE
*/
vae?: components["schemas"]["VaeField"];
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default seamless_output
* @enum {string}
*/
type: "seamless_output";
chore: Regen schema
2023-08-29 00:20:55 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* 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
* @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(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
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
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Image
* @description The image to process
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Show Image
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Displays a provided image using the OS image viewer, and passes it forward in the pipeline.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
ShowImageInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Image
* @description The image to show
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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
};
/** StableDiffusion1ModelCheckpointConfig */
StableDiffusion1ModelCheckpointConfig: {
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/** Model Name */
model_name: string;
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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: {
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/** Model Name */
model_name: string;
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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: {
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/** Model Name */
model_name: string;
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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: {
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/** Model Name */
model_name: string;
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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
};
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
/** StableDiffusionXLModelCheckpointConfig */
StableDiffusionXLModelCheckpointConfig: {
/** Model Name */
model_name: string;
chore(ui): regen types
2023-08-16 01:59:19 +00:00
base_model: components["schemas"]["BaseModelType"];
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Model Type
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_type: "main";
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
/** Path */
path: string;
/** Description */
description?: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Model Format
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_format: "checkpoint";
error?: components["schemas"]["ModelError"];
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
/** Vae */
vae?: string;
/** Config */
config: string;
chore(ui): regen types
2023-08-16 01:59:19 +00:00
variant: components["schemas"]["ModelVariantType"];
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
};
/** StableDiffusionXLModelDiffusersConfig */
StableDiffusionXLModelDiffusersConfig: {
/** Model Name */
model_name: string;
chore(ui): regen types
2023-08-16 01:59:19 +00:00
base_model: components["schemas"]["BaseModelType"];
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Model Type
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_type: "main";
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
/** Path */
path: string;
/** Description */
description?: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Model Format
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_format: "diffusers";
error?: components["schemas"]["ModelError"];
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
/** Vae */
vae?: string;
chore(ui): regen types
2023-08-16 01:59:19 +00:00
variant: components["schemas"]["ModelVariantType"];
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* 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
* @description Experimental per-step parameter easing for denoising steps
*/
StepParamEasingInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
chore(ui): regen types
2023-08-16 01:59:19 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Easing
* @description The easing function to use
* @default Linear
chore(ui): regen types
2023-08-16 01:59:19 +00:00
* @enum {string}
*/
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";
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* 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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default step_param_easing
* @enum {string}
*/
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
};
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
/**
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* String Collection Primitive
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
* @description A collection of string primitive values
*/
StringCollectionInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Collection
* @description The collection of string values
*/
collection?: string[];
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default string_collection
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
type: "string_collection";
feat: add missing primitive collections - add missing primitive collections - remove `Seed` and `LoRAField` (they don't exist)
2023-08-15 12:18:37 +00:00
};
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* StringCollectionOutput
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description Base class for nodes that output a collection of strings
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
*/
StringCollectionOutput: {
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Collection
* @description The output strings
*/
collection: string[];
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default string_collection_output
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @enum {string}
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19:36 +00:00
type: "string_collection_output";
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
};
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* String Primitive
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description A string primitive value
*/
StringInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Value
* @description The string value
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @default
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19:36 +00:00
value?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default string
* @enum {string}
*/
type: "string";
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
};
Merge branch 'main' into release/invokeai-3-0-beta -- this adds the upscaling support
2023-07-19 01:17:15 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* StringOutput
feat(nodes): refactor parameter/primitive nodes Refine concept of "parameter" nodes to "primitives": - integer - float - string - boolean - image - latents - conditioning - color Each primitive has: - A field definition, if it is not already python primitive value. The field is how this primitive value is passed between nodes. Collections are lists of the field in node definitions. ex: `ImageField` & `list[ImageField]` - A single output class. ex: `ImageOutput` - A collection output class. ex: `ImageCollectionOutput` - A node, which functions to load or pass on the primitive value. ex: `ImageInvocation` (in this case, `ImageInvocation` replaces `LoadImage`) Plus a number of related changes: - Reorganize these into `primitives.py` - Update all nodes and logic to use primitives - Consolidate "prompt" outputs into "string" & "mask" into "image" (there's no reason for these to be different, the function identically) - Update default graphs & tests - Regen frontend types & minor frontend tidy related to changes
2023-08-14 09:41:29 +00:00
* @description Base class for nodes that output a single string
Merge branch 'main' into release/invokeai-3-0-beta -- this adds the upscaling support
2023-07-19 01:17:15 +00:00
*/
StringOutput: {
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Value
* @description The output string
*/
value: string;
Merge branch 'main' into release/invokeai-3-0-beta -- this adds the upscaling support
2023-07-19 01:17:15 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default string_output
Merge branch 'main' into release/invokeai-3-0-beta -- this adds the upscaling support
2023-07-19 01:17:15 +00:00
* @enum {string}
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19:36 +00:00
type: "string_output";
Merge branch 'main' into release/invokeai-3-0-beta -- this adds the upscaling support
2023-07-19 01:17:15 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +00:00
SubModelType: "unet" | "text_encoder" | "text_encoder_2" | "tokenizer" | "tokenizer_2" | "vae" | "vae_decoder" | "vae_encoder" | "scheduler" | "safety_checker";
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Subtract Integers
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: 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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Type
* @default sub
* @enum {string}
*/
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
};
/** TextualInversionModelConfig */
TextualInversionModelConfig: {
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/** Model Name */
model_name: string;
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Tile Resample Processor
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @description Tile resampler 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
*/
TileResamplerProcessorInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
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
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Image
* @description The image to process
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +00:00
loras: components["schemas"]["LoraInfo"][];
chore: Regen schema
2023-08-29 00:20:55 +00:00
/**
* Seamless Axes
* @description Axes("x" and "y") to which apply seamless
*/
chore(ui): typegen
2023-09-04 05:25:58 +00:00
seamless_axes?: 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
};
feat(ui): add nsfw & watermark to linear ui - add `addNSFWCheckerToGraph` and `addWatermarkerToGraph` functions - use them in all linear graph creation - add state & toggles to settings modal to enable these - trigger queries for app config on socket connect - disable the nsfw/watermark booleans if we get the app config and they are not available
2023-07-26 08:20:20 +00:00
/** Upscaler */
Upscaler: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Upscaling Method
feat(ui): add nsfw & watermark to linear ui - add `addNSFWCheckerToGraph` and `addWatermarkerToGraph` functions - use them in all linear graph creation - add state & toggles to settings modal to enable these - trigger queries for app config on socket connect - disable the nsfw/watermark booleans if we get the app config and they are not available
2023-07-26 08:20:20 +00:00
* @description Name of upscaling method
*/
upscaling_method: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Upscaling Models
feat(ui): add nsfw & watermark to linear ui - add `addNSFWCheckerToGraph` and `addWatermarkerToGraph` functions - use them in all linear graph creation - add state & toggles to settings modal to enable these - trigger queries for app config on socket connect - disable the nsfw/watermark booleans if we get the app config and they are not available
2023-07-26 08:20:20 +00:00
* @description List of upscaling models for this method
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
upscaling_models: string[];
feat(ui): add nsfw & watermark to linear ui - add `addNSFWCheckerToGraph` and `addWatermarkerToGraph` functions - use them in all linear graph creation - add state & toggles to settings modal to enable these - trigger queries for app config on socket connect - disable the nsfw/watermark booleans if we get the app config and they are not available
2023-07-26 08:20:20 +00:00
};
add vae lodaer
2023-06-30 22:15:04 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* VAEModelField
add vae lodaer
2023-06-30 22:15:04 +00:00
* @description Vae model field
*/
VAEModelField: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Model Name
add vae lodaer
2023-06-30 22:15:04 +00:00
* @description Name of the model
*/
model_name: string;
/** @description Base model */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
base_model: components["schemas"]["BaseModelType"];
add vae lodaer
2023-06-30 22:15:04 +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
/** VaeField */
VaeField: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +00:00
vae: components["schemas"]["ModelInfo"];
chore: Regen schema
2023-08-29 00:20:55 +00:00
/**
* Seamless Axes
* @description Axes("x" and "y") to which apply seamless
*/
chore(ui): typegen
2023-09-04 05:25:58 +00:00
seamless_axes?: 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
};
add vae lodaer
2023-06-30 22:15:04 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* VAE
add vae lodaer
2023-06-30 22:15:04 +00:00
* @description Loads a VAE model, outputting a VaeLoaderOutput
*/
VaeLoaderInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
add vae lodaer
2023-06-30 22:15:04 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
add vae lodaer
2023-06-30 22:15:04 +00:00
* @default false
*/
is_intermediate?: boolean;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* VAE
* @description VAE model to load
*/
vae_model: components["schemas"]["VAEModelField"];
add vae lodaer
2023-06-30 22:15:04 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default vae_loader
add vae lodaer
2023-06-30 22:15:04 +00:00
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
type: "vae_loader";
add vae lodaer
2023-06-30 22:15:04 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* VaeLoaderOutput
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description VAE output
add vae lodaer
2023-06-30 22:15:04 +00:00
*/
VaeLoaderOutput: {
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* VAE
* @description VAE
*/
vae: components["schemas"]["VaeField"];
add vae lodaer
2023-06-30 22:15:04 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Type
* @default vae_loader_output
add vae lodaer
2023-06-30 22:15:04 +00:00
* @enum {string}
*/
feat(ui): add typegen customisation for invocation outputs The `type` property is required on all of them, but because this is defined in pydantic as a Literal, it is not required in the OpenAPI schema. Easier to fix this by changing the generated types than fiddling around with pydantic.
2023-08-18 10:19:36 +00:00
type: "vae_loader_output";
add vae lodaer
2023-06-30 22:15:04 +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
/** VaeModelConfig */
VaeModelConfig: {
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/** Model Name */
model_name: string;
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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
* @enum {string}
*/
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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
/** ValidationError */
ValidationError: {
/** Location */
loc: (string | number)[];
/** Message */
msg: string;
/** Error Type */
type: string;
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Zoe (Depth) 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
* @description Applies Zoe depth processing to image
*/
ZoeDepthImageProcessorInvocation: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Id
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The id of this instance of an invocation. Must be unique among all instances of invocations.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
id: string;
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Is Intermediate
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description Whether or not this is an intermediate invocation.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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;
feat: workflow saving and loading
2023-08-24 11:42:32 +00:00
/**
* Workflow
* @description The workflow to save with the image
*/
workflow?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Image
* @description The image to process
*/
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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +00:00
type: "zoe_depth_image_processor";
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* UIConfigBase
chore(ui): regen types
2023-08-16 01:59:19 +00:00
* @description Provides additional node configuration to the UI.
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* This is used internally by the @invocation decorator logic. Do not use this directly.
chore(ui): regen types
2023-08-16 01:59:19 +00:00
*/
UIConfigBase: {
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Tags
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The node's tags
chore(ui): regen types
2023-08-16 01:59:19 +00:00
*/
chore(ui): typegen
2023-08-22 05:15:00 +00:00
tags?: string[];
chore(ui): regen types
2023-08-16 01:59:19 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Title
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* @description The node's display name
chore(ui): regen types
2023-08-16 01:59:19 +00:00
*/
title?: string;
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* Category
* @description The node's category
*/
category?: string;
chore(ui): regen types
2023-08-16 01:59:19 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Input
chore(ui): regen types
2023-08-16 01:59:19 +00:00
* @description The type of input a field accepts.
* - `Input.Direct`: The field must have its value provided directly, when the invocation and field are instantiated.
* - `Input.Connection`: The field must have its value provided by a connection.
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* - `Input.Any`: The field may have its value provided either directly or by a connection.
chore(ui): regen types
2023-08-16 01:59:19 +00:00
* @enum {string}
*/
Input: "connection" | "direct" | "any";
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* UIType
chore(ui): regen types
2023-08-16 01:59:19 +00:00
* @description Type hints for the UI.
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* If a field should be provided a data type that does not exactly match the python type of the field, use this to provide the type that should be used instead. See the node development docs for detail on adding a new field type, which involves client-side changes.
chore(ui): regen types
2023-08-16 01:59:19 +00:00
* @enum {string}
*/
feat: polymorphic fields Initial support for polymorphic field types. Polymorphic types are a single of or list of a specific type. For example, `Union[str, list[str]]`. Polymorphics do not yet have support for direct input in the UI (will come in the future). They will be forcibly set as Connection-only fields, in which case users will not be able to provide direct input to the field. If a polymorphic should present as a singleton type - which would allow direct input - the node must provide an explicit type hint. For example, `DenoiseLatents`' `CFG Scale` is polymorphic, but in the node editor, we want to present this as a number input. In the node definition, the field is given `ui_type=UIType.Float`, which tells the UI to treat this as a `float` field. The connection validation logic will prevent connecting a collection to `CFG Scale` in this situation, because it is typed as `float`. The workaround is to disable validation from the settings to make this specific connection. A future improvement will resolve this. This also introduces better support for collection field types. Like polymorphics, collection types are parsed automatically by the client and do not need any specific type hints. Also like polymorphics, there is no support yet for direct input of collection types in the UI. - Disabling validation in workflow editor now displays the visual hints for valid connections, but lets you connect to anything. - Added `ui_order: int` to `InputField` and `OutputField`. The UI will use this, if present, to order fields in a node UI. See usage in `DenoiseLatents` for an example. - Updated the field colors - duplicate colors have just been lightened a bit. It's not perfect but it was a quick fix. - Field handles for collections are the same color as their single counterparts, but have a dark dot in the center of them. - Field handles for polymorphics are a rounded square with dot in the middle. - Removed all fields that just render `null` from `InputFieldRenderer`, replaced with a single fallback - Removed logic in `zValidatedWorkflow`, which checked for existence of node templates for each node in a workflow. This logic introduced a circular dependency, due to importing the global redux `store` in order to get the node templates within a zod schema. It's actually fine to just leave this out entirely; The case of a missing node template is handled by the UI. Fixing it otherwise would introduce a substantial headache. - Fixed the `ControlNetInvocation.control_model` field default, which was a string when it shouldn't have one.
2023-09-01 09:40:27 +00:00
UIType: "boolean" | "ColorField" | "ConditioningField" | "ControlField" | "float" | "ImageField" | "integer" | "LatentsField" | "string" | "BooleanCollection" | "ColorCollection" | "ConditioningCollection" | "ControlCollection" | "FloatCollection" | "ImageCollection" | "IntegerCollection" | "LatentsCollection" | "StringCollection" | "BooleanPolymorphic" | "ColorPolymorphic" | "ConditioningPolymorphic" | "ControlPolymorphic" | "FloatPolymorphic" | "ImagePolymorphic" | "IntegerPolymorphic" | "LatentsPolymorphic" | "StringPolymorphic" | "MainModelField" | "SDXLMainModelField" | "SDXLRefinerModelField" | "ONNXModelField" | "VaeModelField" | "LoRAModelField" | "ControlNetModelField" | "UNetField" | "VaeField" | "ClipField" | "Collection" | "CollectionItem" | "enum" | "Scheduler" | "WorkflowField" | "IsIntermediate" | "MetadataField";
chore(ui): regen types
2023-08-16 01:59:19 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* UIComponent
* @description The type of UI component to use for a field, used to override the default components, which are inferred from the field type.
chore(ui): regen types
2023-08-16 01:59:19 +00:00
* @enum {string}
*/
UIComponent: "none" | "textarea" | "slider";
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* _InputField
chore(ui): regen types
2023-08-16 01:59:19 +00:00
* @description *DO NOT USE*
* This helper class is used to tell the client about our custom field attributes via OpenAPI
* schema generation, and Typescript type generation from that schema. It serves no functional
* purpose in the backend.
*/
_InputField: {
input: components["schemas"]["Input"];
/** Ui Hidden */
ui_hidden: boolean;
ui_type?: components["schemas"]["UIType"];
ui_component?: components["schemas"]["UIComponent"];
feat(nodes): add `ui_order` node field attribute used by UI to sort fields in workflow editor
2023-08-22 06:23:20 +00:00
/** Ui Order */
ui_order?: number;
feat: polymorphic fields Initial support for polymorphic field types. Polymorphic types are a single of or list of a specific type. For example, `Union[str, list[str]]`. Polymorphics do not yet have support for direct input in the UI (will come in the future). They will be forcibly set as Connection-only fields, in which case users will not be able to provide direct input to the field. If a polymorphic should present as a singleton type - which would allow direct input - the node must provide an explicit type hint. For example, `DenoiseLatents`' `CFG Scale` is polymorphic, but in the node editor, we want to present this as a number input. In the node definition, the field is given `ui_type=UIType.Float`, which tells the UI to treat this as a `float` field. The connection validation logic will prevent connecting a collection to `CFG Scale` in this situation, because it is typed as `float`. The workaround is to disable validation from the settings to make this specific connection. A future improvement will resolve this. This also introduces better support for collection field types. Like polymorphics, collection types are parsed automatically by the client and do not need any specific type hints. Also like polymorphics, there is no support yet for direct input of collection types in the UI. - Disabling validation in workflow editor now displays the visual hints for valid connections, but lets you connect to anything. - Added `ui_order: int` to `InputField` and `OutputField`. The UI will use this, if present, to order fields in a node UI. See usage in `DenoiseLatents` for an example. - Updated the field colors - duplicate colors have just been lightened a bit. It's not perfect but it was a quick fix. - Field handles for collections are the same color as their single counterparts, but have a dark dot in the center of them. - Field handles for polymorphics are a rounded square with dot in the middle. - Removed all fields that just render `null` from `InputFieldRenderer`, replaced with a single fallback - Removed logic in `zValidatedWorkflow`, which checked for existence of node templates for each node in a workflow. This logic introduced a circular dependency, due to importing the global redux `store` in order to get the node templates within a zod schema. It's actually fine to just leave this out entirely; The case of a missing node template is handled by the UI. Fixing it otherwise would introduce a substantial headache. - Fixed the `ControlNetInvocation.control_model` field default, which was a string when it shouldn't have one.
2023-09-01 09:40:27 +00:00
/** Item Default */
item_default?: unknown;
chore(ui): regen types
2023-08-16 01:59:19 +00:00
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* _OutputField
chore(ui): regen types
2023-08-16 01:59:19 +00:00
* @description *DO NOT USE*
* This helper class is used to tell the client about our custom field attributes via OpenAPI
* schema generation, and Typescript type generation from that schema. It serves no functional
* purpose in the backend.
*/
_OutputField: {
/** Ui Hidden */
ui_hidden: boolean;
ui_type?: components["schemas"]["UIType"];
feat(nodes): add `ui_order` node field attribute used by UI to sort fields in workflow editor
2023-08-22 06:23:20 +00:00
/** Ui Order */
ui_order?: 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(ui): typegen
2023-09-04 05:25:58 +00:00
/**
* StableDiffusionOnnxModelFormat
* @description An enumeration.
* @enum {string}
*/
StableDiffusionOnnxModelFormat: "olive" | "onnx";
wip: Port Outpainting to new backend
2023-08-11 18:15:59 +00:00
/**
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
* StableDiffusion1ModelFormat
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* @description An enumeration.
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @enum {string}
*/
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
StableDiffusion1ModelFormat: "checkpoint" | "diffusers";
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
/**
chore: Regen schema
2023-08-29 00:20:55 +00:00
* ControlNetModelFormat
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* @description An enumeration.
feat: node editor squashed rebase on main after backendd refactor
2023-08-14 03:23:09 +00:00
* @enum {string}
*/
chore: Regen schema
2023-08-29 00:20:55 +00:00
ControlNetModelFormat: "checkpoint" | "diffusers";
/**
* StableDiffusionXLModelFormat
* @description An enumeration.
* @enum {string}
*/
StableDiffusionXLModelFormat: "checkpoint" | "diffusers";
feat(nodes): move all invocation metadata (type, title, tags, category) to decorator All invocation metadata (type, title, tags and category) are now defined in decorators. The decorators add the `type: Literal["invocation_type"]: "invocation_type"` field to the invocation. Category is a new invocation metadata, but it is not used by the frontend just yet. - `@invocation()` decorator for invocations ```py @invocation( "sdxl_compel_prompt", title="SDXL Prompt", tags=["sdxl", "compel", "prompt"], category="conditioning", ) class SDXLCompelPromptInvocation(BaseInvocation, SDXLPromptInvocationBase): ... ``` - `@invocation_output()` decorator for invocation outputs ```py @invocation_output("clip_skip_output") class ClipSkipInvocationOutput(BaseInvocationOutput): ... ``` - update invocation docs - add category to decorator - regen frontend types
2023-08-30 08:35:12 +00:00
/**
* StableDiffusion2ModelFormat
* @description An enumeration.
* @enum {string}
*/
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
};
responses: never;
parameters: never;
requestBodies: never;
headers: never;
pathItems: never;
};
chore(ui): typegen
2023-08-22 05:15:00 +00:00
export type $defs = Record<string, never>;
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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 external = Record<string, never>;
export type operations = {
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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 */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
400: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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 */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
404: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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: typegen
2023-09-02 01:36:07 +00:00
"application/json": components["schemas"]["BooleanInvocation"] | components["schemas"]["BooleanCollectionInvocation"] | components["schemas"]["IntegerInvocation"] | components["schemas"]["IntegerCollectionInvocation"] | components["schemas"]["FloatInvocation"] | components["schemas"]["FloatCollectionInvocation"] | components["schemas"]["StringInvocation"] | components["schemas"]["StringCollectionInvocation"] | components["schemas"]["ImageInvocation"] | components["schemas"]["ImageCollectionInvocation"] | components["schemas"]["LatentsInvocation"] | components["schemas"]["LatentsCollectionInvocation"] | components["schemas"]["ColorInvocation"] | components["schemas"]["ConditioningInvocation"] | components["schemas"]["ConditioningCollectionInvocation"] | components["schemas"]["ControlNetInvocation"] | components["schemas"]["ImageProcessorInvocation"] | components["schemas"]["MainModelLoaderInvocation"] | components["schemas"]["LoraLoaderInvocation"] | components["schemas"]["SDXLLoraLoaderInvocation"] | components["schemas"]["VaeLoaderInvocation"] | components["schemas"]["SeamlessModeInvocation"] | components["schemas"]["MetadataAccumulatorInvocation"] | components["schemas"]["SDXLModelLoaderInvocation"] | components["schemas"]["SDXLRefinerModelLoaderInvocation"] | components["schemas"]["CompelInvocation"] | components["schemas"]["SDXLCompelPromptInvocation"] | components["schemas"]["SDXLRefinerCompelPromptInvocation"] | components["schemas"]["ClipSkipInvocation"] | components["schemas"]["SchedulerInvocation"] | components["schemas"]["CreateDenoiseMaskInvocation"] | components["schemas"]["DenoiseLatentsInvocation"] | components["schemas"]["LatentsToImageInvocation"] | components["schemas"]["ResizeLatentsInvocation"] | components["schemas"]["ScaleLatentsInvocation"] | components["schemas"]["ImageToLatentsInvocation"] | components["schemas"]["BlendLatentsInvocation"] | components["schemas"]["ONNXPromptInvocation"] | components["schemas"]["ONNXTextToLatentsInvocation"] | components["schemas"]["ONNXLatentsToImageInvocation"] | components["schemas"]["OnnxModelLoaderInvocation"] | components["schemas"]["ShowImageInvocation"] | components["schemas"]["BlankImageInvocation"] | 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"] | components["schemas"]["ImageNSFWBlurInvocation"] | components["schemas"]["ImageWatermarkInvocation"] | components["schemas"]["MaskEdgeInvocation"] | components["schemas"]["MaskCombineInvocation"] | components["schemas"]["ColorCorrectInvocation"] | components["schemas"]["ImageHueAdjustmentInvocation"] | components["schemas"]["ImageLuminosityAdjustmentInvocation"] | components["schemas"]["ImageSaturationAdjustmentInvocation"] | components["schemas"]["DynamicPromptInvocation"] | components["schemas"]["PromptsFromFileInvocation"] | components["schemas"]["CvInpaintInvocation"] | components["schemas"]["FloatLinearRangeInvocation"] | components["schemas"]["StepParamEasingInvocation"] | components["schemas"]["AddInvocation"] | components["schemas"]["SubtractInvocation"] | components["schemas"]["MultiplyInvocation"] | components["schemas"]["DivideInvocation"] | components["schemas"]["RandomIntInvocation"] | components["schemas"]["NoiseInvocation"] | components["schemas"]["RangeInvocation"] | components["schemas"]["RangeOfSizeInvocation"] | components["schemas"]["RandomRangeInvocation"] | components["schemas"]["ESRGANInvocation"] | components["schemas"]["InfillColorInvocation"] | components["schemas"]["InfillTileInvocation"] | components["schemas"]["InfillPatchMatchInvocation"] | components["schemas"]["LaMaInfillInvocation"] | co
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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(ui): regen types
2023-08-16 01:59:19 +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 */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
400: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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 */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
404: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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: typegen
2023-09-02 01:36:07 +00:00
"application/json": components["schemas"]["BooleanInvocation"] | components["schemas"]["BooleanCollectionInvocation"] | components["schemas"]["IntegerInvocation"] | components["schemas"]["IntegerCollectionInvocation"] | components["schemas"]["FloatInvocation"] | components["schemas"]["FloatCollectionInvocation"] | components["schemas"]["StringInvocation"] | components["schemas"]["StringCollectionInvocation"] | components["schemas"]["ImageInvocation"] | components["schemas"]["ImageCollectionInvocation"] | components["schemas"]["LatentsInvocation"] | components["schemas"]["LatentsCollectionInvocation"] | components["schemas"]["ColorInvocation"] | components["schemas"]["ConditioningInvocation"] | components["schemas"]["ConditioningCollectionInvocation"] | components["schemas"]["ControlNetInvocation"] | components["schemas"]["ImageProcessorInvocation"] | components["schemas"]["MainModelLoaderInvocation"] | components["schemas"]["LoraLoaderInvocation"] | components["schemas"]["SDXLLoraLoaderInvocation"] | components["schemas"]["VaeLoaderInvocation"] | components["schemas"]["SeamlessModeInvocation"] | components["schemas"]["MetadataAccumulatorInvocation"] | components["schemas"]["SDXLModelLoaderInvocation"] | components["schemas"]["SDXLRefinerModelLoaderInvocation"] | components["schemas"]["CompelInvocation"] | components["schemas"]["SDXLCompelPromptInvocation"] | components["schemas"]["SDXLRefinerCompelPromptInvocation"] | components["schemas"]["ClipSkipInvocation"] | components["schemas"]["SchedulerInvocation"] | components["schemas"]["CreateDenoiseMaskInvocation"] | components["schemas"]["DenoiseLatentsInvocation"] | components["schemas"]["LatentsToImageInvocation"] | components["schemas"]["ResizeLatentsInvocation"] | components["schemas"]["ScaleLatentsInvocation"] | components["schemas"]["ImageToLatentsInvocation"] | components["schemas"]["BlendLatentsInvocation"] | components["schemas"]["ONNXPromptInvocation"] | components["schemas"]["ONNXTextToLatentsInvocation"] | components["schemas"]["ONNXLatentsToImageInvocation"] | components["schemas"]["OnnxModelLoaderInvocation"] | components["schemas"]["ShowImageInvocation"] | components["schemas"]["BlankImageInvocation"] | 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"] | components["schemas"]["ImageNSFWBlurInvocation"] | components["schemas"]["ImageWatermarkInvocation"] | components["schemas"]["MaskEdgeInvocation"] | components["schemas"]["MaskCombineInvocation"] | components["schemas"]["ColorCorrectInvocation"] | components["schemas"]["ImageHueAdjustmentInvocation"] | components["schemas"]["ImageLuminosityAdjustmentInvocation"] | components["schemas"]["ImageSaturationAdjustmentInvocation"] | components["schemas"]["DynamicPromptInvocation"] | components["schemas"]["PromptsFromFileInvocation"] | components["schemas"]["CvInpaintInvocation"] | components["schemas"]["FloatLinearRangeInvocation"] | components["schemas"]["StepParamEasingInvocation"] | components["schemas"]["AddInvocation"] | components["schemas"]["SubtractInvocation"] | components["schemas"]["MultiplyInvocation"] | components["schemas"]["DivideInvocation"] | components["schemas"]["RandomIntInvocation"] | components["schemas"]["NoiseInvocation"] | components["schemas"]["RangeInvocation"] | components["schemas"]["RangeOfSizeInvocation"] | components["schemas"]["RandomRangeInvocation"] | components["schemas"]["ESRGANInvocation"] | components["schemas"]["InfillColorInvocation"] | components["schemas"]["InfillTileInvocation"] | components["schemas"]["InfillPatchMatchInvocation"] | components["schemas"]["LaMaInfillInvocation"] | co
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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(ui): regen types
2023-08-16 01:59:19 +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 */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
400: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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 */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
404: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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 */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
400: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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 */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
404: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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 */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
400: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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 */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
404: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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 */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
400: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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 */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
404: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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 */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
202: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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 has no invocations ready to invoke */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
400: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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 */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
404: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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 */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
202: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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?: {
merge: Make Model Manager work with SDXL stuff
2023-07-18 02:01:56 +00:00
/** @description Base models to include */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
base_models?: 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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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
};
};
};
};
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Delete Model
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
* @description Delete Model
*/
del_model: {
parameters: {
path: {
/** @description Base model */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
base_model: components["schemas"]["BaseModelType"];
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/** @description The type of model */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_type: components["schemas"]["ModelType"];
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/** @description model name */
model_name: 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
};
};
responses: {
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/** @description Model deleted successfully */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
204: {
content: never;
};
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/** @description Model not found */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
404: {
content: never;
};
chore(ui): regen types
2023-07-04 05:04:01 +00:00
/** @description Validation Error */
422: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["HTTPValidationError"];
chore(ui): regen types
2023-07-04 05:04:01 +00:00
};
};
};
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Update Model
chore: regen types
2023-07-17 01:50:35 +00:00
* @description Update model contents with a new config. If the model name or base fields are changed, then the model is renamed.
chore(ui): regen types
2023-07-04 05:04:01 +00:00
*/
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
update_model: {
chore(ui): regen types
2023-07-04 05:04:01 +00:00
parameters: {
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
path: {
/** @description Base model */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
base_model: components["schemas"]["BaseModelType"];
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/** @description The type of model */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_type: components["schemas"]["ModelType"];
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/** @description model name */
model_name: string;
};
};
requestBody: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["ONNXStableDiffusion1ModelConfig"] | components["schemas"]["StableDiffusion1ModelCheckpointConfig"] | components["schemas"]["StableDiffusion1ModelDiffusersConfig"] | components["schemas"]["VaeModelConfig"] | components["schemas"]["LoRAModelConfig"] | components["schemas"]["ControlNetModelCheckpointConfig"] | components["schemas"]["ControlNetModelDiffusersConfig"] | components["schemas"]["TextualInversionModelConfig"] | components["schemas"]["ONNXStableDiffusion2ModelConfig"] | components["schemas"]["StableDiffusion2ModelCheckpointConfig"] | components["schemas"]["StableDiffusion2ModelDiffusersConfig"] | components["schemas"]["StableDiffusionXLModelCheckpointConfig"] | components["schemas"]["StableDiffusionXLModelDiffusersConfig"];
chore(ui): regen types
2023-07-04 05:04:01 +00:00
};
};
responses: {
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/** @description The model was updated successfully */
200: {
chore(ui): regen types
2023-07-04 05:04:01 +00:00
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["ONNXStableDiffusion1ModelConfig"] | components["schemas"]["StableDiffusion1ModelCheckpointConfig"] | components["schemas"]["StableDiffusion1ModelDiffusersConfig"] | components["schemas"]["VaeModelConfig"] | components["schemas"]["LoRAModelConfig"] | components["schemas"]["ControlNetModelCheckpointConfig"] | components["schemas"]["ControlNetModelDiffusersConfig"] | components["schemas"]["TextualInversionModelConfig"] | components["schemas"]["ONNXStableDiffusion2ModelConfig"] | components["schemas"]["StableDiffusion2ModelCheckpointConfig"] | components["schemas"]["StableDiffusion2ModelDiffusersConfig"] | components["schemas"]["StableDiffusionXLModelCheckpointConfig"] | components["schemas"]["StableDiffusionXLModelDiffusersConfig"];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/** @description Bad request */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
400: {
content: never;
};
chore(ui): regen types
2023-07-04 05:04:01 +00:00
/** @description The model could not be found */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
404: {
content: never;
};
chore: regen types
2023-07-17 01:50:35 +00:00
/** @description There is already a model corresponding to the new name */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
409: {
content: never;
};
chore(ui): regen types
2023-07-15 15:06:57 +00:00
/** @description Validation Error */
422: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["HTTPValidationError"];
chore(ui): regen types
2023-07-15 15:06:57 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Import Model
chore(ui): regen types
2023-07-15 15:06:57 +00:00
* @description Add a model using its local path, repo_id, or remote URL. Model characteristics will be probed and configured automatically
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +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(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["Body_import_model"];
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
};
};
responses: {
/** @description The model imported successfully */
201: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["ONNXStableDiffusion1ModelConfig"] | components["schemas"]["StableDiffusion1ModelCheckpointConfig"] | components["schemas"]["StableDiffusion1ModelDiffusersConfig"] | components["schemas"]["VaeModelConfig"] | components["schemas"]["LoRAModelConfig"] | components["schemas"]["ControlNetModelCheckpointConfig"] | components["schemas"]["ControlNetModelDiffusersConfig"] | components["schemas"]["TextualInversionModelConfig"] | components["schemas"]["ONNXStableDiffusion2ModelConfig"] | components["schemas"]["StableDiffusion2ModelCheckpointConfig"] | components["schemas"]["StableDiffusion2ModelDiffusersConfig"] | components["schemas"]["StableDiffusionXLModelCheckpointConfig"] | components["schemas"]["StableDiffusionXLModelDiffusersConfig"];
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
};
};
/** @description The model could not be found */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
404: {
content: never;
};
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/** @description There is already a model corresponding to this path or repo_id */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
409: {
content: never;
};
chore: Clean Schema before final merge
2023-07-18 03:18:31 +00:00
/** @description Unrecognized file/folder format */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
415: {
content: never;
};
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/** @description Validation Error */
422: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["HTTPValidationError"];
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
};
};
/** @description The model appeared to import successfully, but could not be found in the model manager */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
424: {
content: never;
};
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
};
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Add Model
chore(ui): regen types
2023-07-15 15:06:57 +00:00
* @description Add a model using the configuration information appropriate for its type. Only local models can be added by path
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
*/
chore(ui): regen types
2023-07-15 15:06:57 +00:00
add_model: {
requestBody: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["ONNXStableDiffusion1ModelConfig"] | components["schemas"]["StableDiffusion1ModelCheckpointConfig"] | components["schemas"]["StableDiffusion1ModelDiffusersConfig"] | components["schemas"]["VaeModelConfig"] | components["schemas"]["LoRAModelConfig"] | components["schemas"]["ControlNetModelCheckpointConfig"] | components["schemas"]["ControlNetModelDiffusersConfig"] | components["schemas"]["TextualInversionModelConfig"] | components["schemas"]["ONNXStableDiffusion2ModelConfig"] | components["schemas"]["StableDiffusion2ModelCheckpointConfig"] | components["schemas"]["StableDiffusion2ModelDiffusersConfig"] | components["schemas"]["StableDiffusionXLModelCheckpointConfig"] | components["schemas"]["StableDiffusionXLModelDiffusersConfig"];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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: {
chore(ui): regen types
2023-07-15 15:06:57 +00:00
/** @description The model added successfully */
201: {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["ONNXStableDiffusion1ModelConfig"] | components["schemas"]["StableDiffusion1ModelCheckpointConfig"] | components["schemas"]["StableDiffusion1ModelDiffusersConfig"] | components["schemas"]["VaeModelConfig"] | components["schemas"]["LoRAModelConfig"] | components["schemas"]["ControlNetModelCheckpointConfig"] | components["schemas"]["ControlNetModelDiffusersConfig"] | components["schemas"]["TextualInversionModelConfig"] | components["schemas"]["ONNXStableDiffusion2ModelConfig"] | components["schemas"]["StableDiffusion2ModelCheckpointConfig"] | components["schemas"]["StableDiffusion2ModelDiffusersConfig"] | components["schemas"]["StableDiffusionXLModelCheckpointConfig"] | components["schemas"]["StableDiffusionXLModelDiffusersConfig"];
chore(ui): regen types
2023-07-04 05:04:01 +00:00
};
};
chore(ui): regen types
2023-07-15 15:06:57 +00:00
/** @description The model could not be found */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
404: {
content: never;
};
chore(ui): regen types
2023-07-15 15:06:57 +00:00
/** @description There is already a model corresponding to this path or repo_id */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
409: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-07-15 15:06:57 +00:00
/** @description The model appeared to add successfully, but could not be found in the model manager */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
424: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Convert Model
chore(ui): regen types
2023-07-15 15:06:57 +00:00
* @description Convert a checkpoint model into a diffusers model, optionally saving to the indicated destination directory, or `models` if none.
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
convert_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
parameters: {
chore(ui): regen types
2023-07-15 15:06:57 +00:00
query?: {
/** @description Save the converted model to the designated directory */
convert_dest_directory?: 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
path: {
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/** @description Base model */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
base_model: components["schemas"]["BaseModelType"];
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/** @description The type of model */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
model_type: components["schemas"]["ModelType"];
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/** @description 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
model_name: string;
};
};
responses: {
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/** @description Model converted successfully */
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
200: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["ONNXStableDiffusion1ModelConfig"] | components["schemas"]["StableDiffusion1ModelCheckpointConfig"] | components["schemas"]["StableDiffusion1ModelDiffusersConfig"] | components["schemas"]["VaeModelConfig"] | components["schemas"]["LoRAModelConfig"] | components["schemas"]["ControlNetModelCheckpointConfig"] | components["schemas"]["ControlNetModelDiffusersConfig"] | components["schemas"]["TextualInversionModelConfig"] | components["schemas"]["ONNXStableDiffusion2ModelConfig"] | components["schemas"]["StableDiffusion2ModelCheckpointConfig"] | components["schemas"]["StableDiffusion2ModelDiffusersConfig"] | components["schemas"]["StableDiffusionXLModelCheckpointConfig"] | components["schemas"]["StableDiffusionXLModelDiffusersConfig"];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/** @description Bad request */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
400: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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 not found */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
404: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-07-15 15:06:57 +00:00
/** Search For Models */
search_for_models: {
parameters: {
query: {
/** @description Directory path to search for models */
search_path: string;
};
};
responses: {
/** @description Directory searched successfully */
200: {
content: {
chore(ui): typegen
2023-08-22 05:15:00 +00:00
"application/json": string[];
chore(ui): regen types
2023-07-15 15:06:57 +00:00
};
};
/** @description Invalid directory path */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
404: {
content: never;
};
chore(ui): regen types
2023-07-15 15:06:57 +00:00
/** @description Validation Error */
422: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["HTTPValidationError"];
chore(ui): regen types
2023-07-15 15:06:57 +00:00
};
};
};
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* List Ckpt Configs
chore(ui): regen types
2023-07-15 15:06:57 +00:00
* @description Return a list of the legacy checkpoint configuration files stored in `ROOT/configs/stable-diffusion`, relative to ROOT.
*/
list_ckpt_configs: {
responses: {
/** @description paths retrieved successfully */
200: {
content: {
chore(ui): typegen
2023-08-22 05:15:00 +00:00
"application/json": string[];
chore(ui): regen types
2023-07-15 15:06:57 +00:00
};
};
};
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Sync To Config
chore(ui): regen types
2023-07-15 15:06:57 +00:00
* @description Call after making changes to models.yaml, autoimport directories or models directory to synchronize
* in-memory data structures with disk data structures.
*/
sync_to_config: {
responses: {
/** @description synchronization successful */
201: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": boolean;
chore(ui): regen types
2023-07-15 15:06:57 +00:00
};
};
};
};
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Merge Models
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
* @description Convert a checkpoint model into a diffusers model
*/
merge_models: {
parameters: {
path: {
/** @description Base model */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
base_model: components["schemas"]["BaseModelType"];
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
};
};
requestBody: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["Body_merge_models"];
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
};
};
responses: {
/** @description Model converted successfully */
200: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["ONNXStableDiffusion1ModelConfig"] | components["schemas"]["StableDiffusion1ModelCheckpointConfig"] | components["schemas"]["StableDiffusion1ModelDiffusersConfig"] | components["schemas"]["VaeModelConfig"] | components["schemas"]["LoRAModelConfig"] | components["schemas"]["ControlNetModelCheckpointConfig"] | components["schemas"]["ControlNetModelDiffusersConfig"] | components["schemas"]["TextualInversionModelConfig"] | components["schemas"]["ONNXStableDiffusion2ModelConfig"] | components["schemas"]["StableDiffusion2ModelCheckpointConfig"] | components["schemas"]["StableDiffusion2ModelDiffusersConfig"] | components["schemas"]["StableDiffusionXLModelCheckpointConfig"] | components["schemas"]["StableDiffusionXLModelDiffusersConfig"];
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
};
};
/** @description Incompatible models */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
400: {
content: never;
};
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/** @description One or more models not found */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
404: {
content: never;
};
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +00:00
/** @description Validation Error */
422: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["HTTPValidationError"];
feat(ui): update `openapi-fetch`; fix upload issue My PR to fix an issue with the handling of formdata in `openapi-fetch` is released. This means we no longer need to patch the package (no patches at all now!). This PR bumps its version and adds a transformer to our typegen script to handle typing binary form fields correctly as `Blob`. Also regens types.
2023-07-07 06:08:30 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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;
feat(ui): fix more caching bugs
2023-07-21 07:45:12 +00:00
/** @description The board to add this image to, if any */
board_id?: 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 The session ID associated with this upload, if any */
session_id?: string;
fix(api,ui): fix canvas saved images have extra transparent regions - add `crop_visible` param to upload image & set to true only for canvas saves
2023-07-21 11:16:46 +00:00
/** @description Whether to crop the image */
crop_visible?: 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
};
};
requestBody: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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 */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
415: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Get Image Dto
chore(ui): regen types
2023-07-12 15:15:09 +00:00
* @description Gets an image's DTO
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
*/
chore(ui): regen types
2023-07-12 15:15:09 +00:00
get_image_dto: {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
parameters: {
path: {
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/** @description The name of image to get */
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
image_name: string;
};
};
responses: {
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/** @description Successful Response */
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
200: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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
};
};
};
};
Maryhipp/clear intermediates (#3820) * new route to clear intermediates * UI to clear intermediates from settings modal * cleanup * PR feedback --------- Co-authored-by: Mary Hipp <maryhipp@Marys-MacBook-Air.local>
2023-07-19 14:55:29 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Clear Intermediates
feat: Add ControlNet Resize Mode to Linear UI
2023-07-20 10:48:35 +00:00
* @description Clears all intermediates
Maryhipp/clear intermediates (#3820) * new route to clear intermediates * UI to clear intermediates from settings modal * cleanup * PR feedback --------- Co-authored-by: Mary Hipp <maryhipp@Marys-MacBook-Air.local>
2023-07-19 14:55:29 +00:00
*/
clear_intermediates: {
responses: {
/** @description Successful Response */
200: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": unknown;
Maryhipp/clear intermediates (#3820) * new route to clear intermediates * UI to clear intermediates from settings modal * cleanup * PR feedback --------- Co-authored-by: Mary Hipp <maryhipp@Marys-MacBook-Air.local>
2023-07-19 14:55:29 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": 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
};
};
/** @description Validation Error */
422: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-07-12 15:15:09 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Get Image Full
chore(ui): regen types
2023-07-12 15:15:09 +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(ui): regen types
2023-08-16 01:59:19 +00:00
"image/png": unknown;
chore(ui): regen types
2023-07-12 15:15:09 +00:00
};
};
/** @description Image not found */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
404: {
content: never;
};
chore(ui): regen types
2023-07-12 15:15:09 +00:00
/** @description Validation Error */
422: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["HTTPValidationError"];
chore(ui): regen types
2023-07-12 15:15:09 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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 */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
404: {
content: never;
};
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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
};
};
};
};
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* List Image Dtos
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
* @description Gets a list of image DTOs
*/
list_image_dtos: {
parameters: {
query?: {
/** @description The origin of images to list. */
chore(ui): regen types
2023-08-16 01:59:19 +00:00
image_origin?: components["schemas"]["ResourceOrigin"];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
/** @description The categories of image to include. */
chore(ui): typegen
2023-08-22 05:15:00 +00:00
categories?: components["schemas"]["ImageCategory"][];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
/** @description Whether to list intermediate images. */
is_intermediate?: boolean;
/** @description The board id to filter by. Use 'none' to find images without a board. */
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(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["OffsetPaginatedResults_ImageDTO_"];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["HTTPValidationError"];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
};
};
};
};
/** Delete Images From List */
delete_images_from_list: {
requestBody: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["Body_delete_images_from_list"];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["DeleteImagesFromListResult"];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["HTTPValidationError"];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
};
};
};
};
rename pin to star, add multiselect and remove single image update api
2023-08-15 16:55:28 +00:00
/** Star Images In List */
star_images_in_list: {
requestBody: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["Body_star_images_in_list"];
rename pin to star, add multiselect and remove single image update api
2023-08-15 16:55:28 +00:00
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["ImagesUpdatedFromListResult"];
rename pin to star, add multiselect and remove single image update api
2023-08-15 16:55:28 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["HTTPValidationError"];
rename pin to star, add multiselect and remove single image update api
2023-08-15 16:55:28 +00:00
};
};
};
};
/** Unstar Images In List */
unstar_images_in_list: {
requestBody: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["Body_unstar_images_in_list"];
rename pin to star, add multiselect and remove single image update api
2023-08-15 16:55:28 +00:00
};
};
responses: {
/** @description Successful Response */
200: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["ImagesUpdatedFromListResult"];
rename pin to star, add multiselect and remove single image update api
2023-08-15 16:55:28 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["HTTPValidationError"];
rename pin to star, add multiselect and remove single image update api
2023-08-15 16:55:28 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["DeleteBoardResult"];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query 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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* List All Board Image Names
feat(ui): another go at gallery (#3791) * feat(ui): migrate listImages to RTK query using createEntityAdapter - see comments in `endpoints/images.ts` for explanation of the caching - so far, only manually updating `all` images when new image is generated. no other manual cache updates are implemented, but will be needed. - fixed some weirdness with loading state components (like the spinners in gallery) - added `useThumbnailFallback` for `IAIDndImage`, this displays the tiny webp thumbnail while the full-size images load - comment out some old thunk related stuff in gallerySlice, which is no longer needed * feat(ui): add manual cache updates for board changes (wip) - update RTK Query caches when adding/removing single image to/from board - work more on migrating all image-related operations to RTK Query * update AddImagesToBoardContext so that it works when user uses context menu + modal * handle case where no image is selected * get assets working for main list and boards - dnd only * feat(ui): migrate image uploads to RTK Query - minor refactor of `ImageUploader` and `useImageUploadButton` hooks, simplify some logic - style filesystem upload overlay to match existing UI - replace all old `imageUploaded` thunks with `uploadImage` RTK Query calls, update associated logic including canvas related uploads - simplify `PostUploadAction`s that only need to display user input * feat(ui): remove `receivedPageOfImages` thunks * feat(ui): remove `receivedImageUrls` thunk * feat(ui): finish removing all images thunks stuff now broken: - image usage - delete board images - on first load, no image selected * feat(ui): simplify `updateImage` cache manipulation - we don't actually ever change categories, so we can remove a lot of logic * feat(ui): simplify canvas autosave - instead of using a network request to set the canvas generation as not intermediate, we can just do that in the graph * feat(ui): simplify & handle edge cases in cache updates * feat(db, api): support `board_id='none'` for `get_many` images queries This allows us to get all images that are not on a board. * chore(ui): regen types * feat(ui): add `All Assets`, `No Board` boards Restructure boards: - `all images` is all images - `all assets` is all assets - `no board` is all images/assets without a board set - user boards may have images and assets Update caching logic - much simpler without every board having sub-views of images and assets - update drag and drop operations for all possible interactions * chore(ui): regen types * feat(ui): move download to top of context menu * feat(ui): improve drop overlay styles * fix(ui): fix image not selected on first load - listen for first load of all images board, then select the first image * feat(ui): refactor board deletion api changes: - add route to list all image names for a board. this is required to handle board + image deletion. we need to know every image in the board to determine the image usage across the app. this is fetched only when the delete board and images modal is opened so it's as efficient as it can be. - update the delete board route to respond with a list of deleted `board_images` and `images`, as image names. this is needed to perform accurate clientside state & cache updates after deleting. db changes: - remove unused `board_images` service method to get paginated images dtos for a board. this is now done thru the list images endpoint & images service. needs a small logic change on `images.delete_images_on_board` ui changes: - simplify the delete board modal - no context, just minor prop drilling. this is feasible for boards only because the components that need to trigger and manipulate the modal are very close together in the tree - add cache updates for `deleteBoard` & `deleteBoardAndImages` mutations - the only thing we cannot do directly is on `deleteBoardAndImages`, update the `No Board` board. we'd need to insert image dtos that we may not have loaded. instead, i am just invalidating the tags for that `listImages` cache. so when you `deleteBoardAndImages`, the `No Board` will re-fetch the initial image limit. i think this is more efficient than e.g. fetching all image dtos to insert then inserting them. - handle image usage for `deleteBoardAndImages` - update all (i think/hope) the little bits and pieces in the UI to accomodate these changes * fix(ui): fix board selection logic * feat(ui): add delete board modal loading state * fix(ui): use thumbnails for board cover images * fix(ui): fix race condition with board selection when selecting a board that doesn't have any images loaded, we need to wait until the images haveloaded before selecting the first image. this logic is debounced to ~1000ms. * feat(ui): name 'No Board' correctly, change icon * fix(ui): do not cache listAllImageNames query if we cache it, we can end up with stale image usage during deletion. we could of course manually update the cache as we are doing elsewhere. but because this is a relatively infrequent network request, i'd like to trade increased cache mgmt complexity here for increased resource usage. * feat(ui): reduce drag preview opacity, remove border * fix(ui): fix incorrect queryArg used in `deleteImage` and `updateImage` cache updates * fix(ui): fix doubled open in new tab * fix(ui): fix new generations not getting added to 'No Board' * fix(ui): fix board id not changing on new image when autosave enabled * fix(ui): context menu when selection is 0 need to revise how context menu is triggered later, when we approach multi select * fix(ui): fix deleting does not update counts for all images and all assets * fix(ui): fix all assets board name in boards list collapse button * fix(ui): ensure we never go under 0 for total board count * fix(ui): fix text overflow on board names --------- Co-authored-by: Mary Hipp <maryhipp@Marys-MacBook-Air.local>
2023-07-19 16:06:38 +00:00
* @description Gets a list of images for a 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
*/
feat(ui): another go at gallery (#3791) * feat(ui): migrate listImages to RTK query using createEntityAdapter - see comments in `endpoints/images.ts` for explanation of the caching - so far, only manually updating `all` images when new image is generated. no other manual cache updates are implemented, but will be needed. - fixed some weirdness with loading state components (like the spinners in gallery) - added `useThumbnailFallback` for `IAIDndImage`, this displays the tiny webp thumbnail while the full-size images load - comment out some old thunk related stuff in gallerySlice, which is no longer needed * feat(ui): add manual cache updates for board changes (wip) - update RTK Query caches when adding/removing single image to/from board - work more on migrating all image-related operations to RTK Query * update AddImagesToBoardContext so that it works when user uses context menu + modal * handle case where no image is selected * get assets working for main list and boards - dnd only * feat(ui): migrate image uploads to RTK Query - minor refactor of `ImageUploader` and `useImageUploadButton` hooks, simplify some logic - style filesystem upload overlay to match existing UI - replace all old `imageUploaded` thunks with `uploadImage` RTK Query calls, update associated logic including canvas related uploads - simplify `PostUploadAction`s that only need to display user input * feat(ui): remove `receivedPageOfImages` thunks * feat(ui): remove `receivedImageUrls` thunk * feat(ui): finish removing all images thunks stuff now broken: - image usage - delete board images - on first load, no image selected * feat(ui): simplify `updateImage` cache manipulation - we don't actually ever change categories, so we can remove a lot of logic * feat(ui): simplify canvas autosave - instead of using a network request to set the canvas generation as not intermediate, we can just do that in the graph * feat(ui): simplify & handle edge cases in cache updates * feat(db, api): support `board_id='none'` for `get_many` images queries This allows us to get all images that are not on a board. * chore(ui): regen types * feat(ui): add `All Assets`, `No Board` boards Restructure boards: - `all images` is all images - `all assets` is all assets - `no board` is all images/assets without a board set - user boards may have images and assets Update caching logic - much simpler without every board having sub-views of images and assets - update drag and drop operations for all possible interactions * chore(ui): regen types * feat(ui): move download to top of context menu * feat(ui): improve drop overlay styles * fix(ui): fix image not selected on first load - listen for first load of all images board, then select the first image * feat(ui): refactor board deletion api changes: - add route to list all image names for a board. this is required to handle board + image deletion. we need to know every image in the board to determine the image usage across the app. this is fetched only when the delete board and images modal is opened so it's as efficient as it can be. - update the delete board route to respond with a list of deleted `board_images` and `images`, as image names. this is needed to perform accurate clientside state & cache updates after deleting. db changes: - remove unused `board_images` service method to get paginated images dtos for a board. this is now done thru the list images endpoint & images service. needs a small logic change on `images.delete_images_on_board` ui changes: - simplify the delete board modal - no context, just minor prop drilling. this is feasible for boards only because the components that need to trigger and manipulate the modal are very close together in the tree - add cache updates for `deleteBoard` & `deleteBoardAndImages` mutations - the only thing we cannot do directly is on `deleteBoardAndImages`, update the `No Board` board. we'd need to insert image dtos that we may not have loaded. instead, i am just invalidating the tags for that `listImages` cache. so when you `deleteBoardAndImages`, the `No Board` will re-fetch the initial image limit. i think this is more efficient than e.g. fetching all image dtos to insert then inserting them. - handle image usage for `deleteBoardAndImages` - update all (i think/hope) the little bits and pieces in the UI to accomodate these changes * fix(ui): fix board selection logic * feat(ui): add delete board modal loading state * fix(ui): use thumbnails for board cover images * fix(ui): fix race condition with board selection when selecting a board that doesn't have any images loaded, we need to wait until the images haveloaded before selecting the first image. this logic is debounced to ~1000ms. * feat(ui): name 'No Board' correctly, change icon * fix(ui): do not cache listAllImageNames query if we cache it, we can end up with stale image usage during deletion. we could of course manually update the cache as we are doing elsewhere. but because this is a relatively infrequent network request, i'd like to trade increased cache mgmt complexity here for increased resource usage. * feat(ui): reduce drag preview opacity, remove border * fix(ui): fix incorrect queryArg used in `deleteImage` and `updateImage` cache updates * fix(ui): fix doubled open in new tab * fix(ui): fix new generations not getting added to 'No Board' * fix(ui): fix board id not changing on new image when autosave enabled * fix(ui): context menu when selection is 0 need to revise how context menu is triggered later, when we approach multi select * fix(ui): fix deleting does not update counts for all images and all assets * fix(ui): fix all assets board name in boards list collapse button * fix(ui): ensure we never go under 0 for total board count * fix(ui): fix text overflow on board names --------- Co-authored-by: Mary Hipp <maryhipp@Marys-MacBook-Air.local>
2023-07-19 16:06:38 +00:00
list_all_board_image_names: {
parameters: {
path: {
/** @description The id of the board */
board_id: 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
};
};
responses: {
feat(ui): another go at gallery (#3791) * feat(ui): migrate listImages to RTK query using createEntityAdapter - see comments in `endpoints/images.ts` for explanation of the caching - so far, only manually updating `all` images when new image is generated. no other manual cache updates are implemented, but will be needed. - fixed some weirdness with loading state components (like the spinners in gallery) - added `useThumbnailFallback` for `IAIDndImage`, this displays the tiny webp thumbnail while the full-size images load - comment out some old thunk related stuff in gallerySlice, which is no longer needed * feat(ui): add manual cache updates for board changes (wip) - update RTK Query caches when adding/removing single image to/from board - work more on migrating all image-related operations to RTK Query * update AddImagesToBoardContext so that it works when user uses context menu + modal * handle case where no image is selected * get assets working for main list and boards - dnd only * feat(ui): migrate image uploads to RTK Query - minor refactor of `ImageUploader` and `useImageUploadButton` hooks, simplify some logic - style filesystem upload overlay to match existing UI - replace all old `imageUploaded` thunks with `uploadImage` RTK Query calls, update associated logic including canvas related uploads - simplify `PostUploadAction`s that only need to display user input * feat(ui): remove `receivedPageOfImages` thunks * feat(ui): remove `receivedImageUrls` thunk * feat(ui): finish removing all images thunks stuff now broken: - image usage - delete board images - on first load, no image selected * feat(ui): simplify `updateImage` cache manipulation - we don't actually ever change categories, so we can remove a lot of logic * feat(ui): simplify canvas autosave - instead of using a network request to set the canvas generation as not intermediate, we can just do that in the graph * feat(ui): simplify & handle edge cases in cache updates * feat(db, api): support `board_id='none'` for `get_many` images queries This allows us to get all images that are not on a board. * chore(ui): regen types * feat(ui): add `All Assets`, `No Board` boards Restructure boards: - `all images` is all images - `all assets` is all assets - `no board` is all images/assets without a board set - user boards may have images and assets Update caching logic - much simpler without every board having sub-views of images and assets - update drag and drop operations for all possible interactions * chore(ui): regen types * feat(ui): move download to top of context menu * feat(ui): improve drop overlay styles * fix(ui): fix image not selected on first load - listen for first load of all images board, then select the first image * feat(ui): refactor board deletion api changes: - add route to list all image names for a board. this is required to handle board + image deletion. we need to know every image in the board to determine the image usage across the app. this is fetched only when the delete board and images modal is opened so it's as efficient as it can be. - update the delete board route to respond with a list of deleted `board_images` and `images`, as image names. this is needed to perform accurate clientside state & cache updates after deleting. db changes: - remove unused `board_images` service method to get paginated images dtos for a board. this is now done thru the list images endpoint & images service. needs a small logic change on `images.delete_images_on_board` ui changes: - simplify the delete board modal - no context, just minor prop drilling. this is feasible for boards only because the components that need to trigger and manipulate the modal are very close together in the tree - add cache updates for `deleteBoard` & `deleteBoardAndImages` mutations - the only thing we cannot do directly is on `deleteBoardAndImages`, update the `No Board` board. we'd need to insert image dtos that we may not have loaded. instead, i am just invalidating the tags for that `listImages` cache. so when you `deleteBoardAndImages`, the `No Board` will re-fetch the initial image limit. i think this is more efficient than e.g. fetching all image dtos to insert then inserting them. - handle image usage for `deleteBoardAndImages` - update all (i think/hope) the little bits and pieces in the UI to accomodate these changes * fix(ui): fix board selection logic * feat(ui): add delete board modal loading state * fix(ui): use thumbnails for board cover images * fix(ui): fix race condition with board selection when selecting a board that doesn't have any images loaded, we need to wait until the images haveloaded before selecting the first image. this logic is debounced to ~1000ms. * feat(ui): name 'No Board' correctly, change icon * fix(ui): do not cache listAllImageNames query if we cache it, we can end up with stale image usage during deletion. we could of course manually update the cache as we are doing elsewhere. but because this is a relatively infrequent network request, i'd like to trade increased cache mgmt complexity here for increased resource usage. * feat(ui): reduce drag preview opacity, remove border * fix(ui): fix incorrect queryArg used in `deleteImage` and `updateImage` cache updates * fix(ui): fix doubled open in new tab * fix(ui): fix new generations not getting added to 'No Board' * fix(ui): fix board id not changing on new image when autosave enabled * fix(ui): context menu when selection is 0 need to revise how context menu is triggered later, when we approach multi select * fix(ui): fix deleting does not update counts for all images and all assets * fix(ui): fix all assets board name in boards list collapse button * fix(ui): ensure we never go under 0 for total board count * fix(ui): fix text overflow on board names --------- Co-authored-by: Mary Hipp <maryhipp@Marys-MacBook-Air.local>
2023-07-19 16:06:38 +00:00
/** @description Successful Response */
200: {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
content: {
chore(ui): typegen
2023-08-22 05:15:00 +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 Validation Error */
422: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Add Image To 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_image
*/
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
add_image_to_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
requestBody: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["Body_add_image_to_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
};
};
responses: {
/** @description The image was added to a board successfully */
201: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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(ui): typegen
2023-08-22 05:15:00 +00:00
* Remove Image From Board
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
* @description Removes an image from its board, if it had one
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
remove_image_from_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
requestBody: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["Body_remove_image_from_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
};
};
responses: {
/** @description The image was removed from the board successfully */
201: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +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(ui): regen types
2023-08-16 01:59:19 +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
};
};
};
};
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Add Images To Board
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
* @description Adds a list of images to a board
*/
add_images_to_board: {
requestBody: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["Body_add_images_to_board"];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
};
};
responses: {
/** @description Images were added to board successfully */
201: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["AddImagesToBoardResult"];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["HTTPValidationError"];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
};
};
};
};
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Remove Images From Board
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
* @description Removes a list of images from their board, if they had one
*/
remove_images_from_board: {
requestBody: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["Body_remove_images_from_board"];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
};
};
responses: {
/** @description Images were removed from board successfully */
201: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["RemoveImagesFromBoardResult"];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["HTTPValidationError"];
feat: add multi-select to gallery multi-select actions include: - drag to board to move all to that board - right click to add all to board or delete all backend changes: - add routes for changing board for list of image names, deleting list of images - change image-specific routes to `images/i/{image_name}` to not clobber other routes (like `images/upload`, `images/delete`) - subclass pydantic `BaseModel` as `BaseModelExcludeNull`, which excludes null values when calling `dict()` on the model. this fixes inconsistent types related to JSON parsing null values into `null` instead of `undefined` - remove `board_id` from `remove_image_from_board` frontend changes: - multi-selection stuff uses `ImageDTO[]` as payloads, for dnd and other mutations. this gives us access to image `board_id`s when hitting routes, and enables efficient cache updates. - consolidate change board and delete image modals to handle single and multiples - board totals are now re-fetched on mutation and not kept in sync manually - was way too tedious to do this - fixed warning about nested `<p>` elements - closes #4088 , need to handle case when `autoAddBoardId` is `"none"` - add option to show gallery image delete button on every gallery image frontend refactors/organisation: - make typegen script js instead of ts - enable `noUncheckedIndexedAccess` to help avoid bugs when indexing into arrays, many small changes needed to satisfy TS after this - move all image-related endpoints into `endpoints/images.ts`, its a big file now, but this fixes a number of circular dependency issues that were otherwise felt impossible to resolve
2023-07-31 08:16:52 +00:00
};
};
};
};
feat: Add App Version to UI
2023-07-08 09:31:17 +00:00
/** Get Version */
app_version: {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-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(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["AppVersion"];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
detect if user has patchmatch enabled
2023-07-12 15:56:40 +00:00
};
};
/** Get Config */
get_config: {
responses: {
/** @description Successful Response */
200: {
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["AppConfig"];
feat(ui): api layer refactor *migrate from `openapi-typescript-codegen` to `openapi-typescript` and `openapi-fetch`* `openapi-typescript-codegen` is not very actively maintained - it's been over a year since the last update. `openapi-typescript` and `openapi-fetch` are part of the actively maintained repo. key differences: - provides a `fetch` client instead of `axios`, which means we need to be a bit more verbose with typing thunks - fetch client is created at runtime and has a very nice typescript DX - generates a single file with all types in it, from which we then extract individual types. i don't like how verbose this is, but i do like how it is more explicit. - removed npm api generation scripts - now we have a single `typegen` script overall i have more confidence in this new library. *use nanostores for api base and token* very simple reactive store for api base url and token. this was suggested in the `openapi-fetch` docs and i quite like the strategy. *organise rtk-query api* split out each endpoint (models, images, boards, boardImages) into their own api extensions. tidy!
2023-06-23 09:14:13 +00:00
};
};
};
};
merge with main
2023-07-20 15:45:54 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Get Log Level
merge with main
2023-07-20 15:45:54 +00:00
* @description Returns the log level
*/
get_log_level: {
feat: Add App Version to UI
2023-07-08 09:31:17 +00:00
responses: {
merge with main
2023-07-20 15:45:54 +00:00
/** @description The operation was successful */
feat: Add App Version to UI
2023-07-08 09:31:17 +00:00
200: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["LogLevel"];
detect if user has patchmatch enabled
2023-07-12 15:56:40 +00:00
};
};
};
};
merge with main
2023-07-20 15:45:54 +00:00
/**
chore(ui): typegen
2023-08-22 05:15:00 +00:00
* Set Log Level
merge with main
2023-07-20 15:45:54 +00:00
* @description Sets the log verbosity level
*/
set_log_level: {
requestBody: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["LogLevel"];
merge with main
2023-07-20 15:45:54 +00:00
};
};
detect if user has patchmatch enabled
2023-07-12 15:56:40 +00:00
responses: {
merge with main
2023-07-20 15:45:54 +00:00
/** @description The operation was successful */
detect if user has patchmatch enabled
2023-07-12 15:56:40 +00:00
200: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["LogLevel"];
merge with main
2023-07-20 15:45:54 +00:00
};
};
/** @description Validation Error */
422: {
content: {
chore(ui): regen types
2023-08-16 01:59:19 +00:00
"application/json": components["schemas"]["HTTPValidationError"];
feat: Add App Version to UI
2023-07-08 09:31:17 +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
};
Reference in New Issue Copy Permalink