Skip to content

Incremental Loading and other breaking V3 changes#16

Open
UncleSamSwiss wants to merge 23 commits intomainfrom
incremental-loading
Open

Incremental Loading and other breaking V3 changes#16
UncleSamSwiss wants to merge 23 commits intomainfrom
incremental-loading

Conversation

@UncleSamSwiss
Copy link
Collaborator

@UncleSamSwiss UncleSamSwiss commented Feb 16, 2026

The "sibling" of this PR for the GUI components is: ioBroker/dm-gui-components#247

Caution

The next release of dm-utils should have version 3.0.0 to make clear, this is a breaking change and that it is using version 3 of the message protocol.

@UncleSamSwiss UncleSamSwiss changed the title Fixed name of custom messagebox setting Incremental Loading and other breaking V2 changes Feb 16, 2026
But also make clear that common.messagebox should be replaced by common.supportedMessages.custom
Mainly, progress was completely wrong on the client side because types were not reusable
Copy link
Collaborator

@GermanBluefox GermanBluefox left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

export type DeviceId = string | number | ComplexDeviceId;

export type ValueOrObject<T> = T | { objectId: string; property: string };
export type ValueOrState<T, M = { [value: string | number]: string }> = T | { stateId: string; mapping?: M };
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the notation [value: string | number]: X we could add the additional information about what is meant with key. Isn't it?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We always want a mapping from ioBroker state value to the type of the ValueOrState. That was the reason I changed the mapping to Record<string | number, T>. Otherwise every time we have to say how the mapping should look like.
True, we can't force the mapping to contain every possible value of T (in case it is a string union or similar), but turning the mapping around (i.e. Record<T, string | number>) seems weird and doesn't work for boolean.
Keeping M = { [value: string | number]: string } would force every mapping to be "redefined".

Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

GermanBluefox and others added 3 commits February 25, 2026 12:35
v2 is already used by matter@1.0.0 and we would cause breaking API changes
@UncleSamSwiss UncleSamSwiss changed the title Incremental Loading and other breaking V2 changes Incremental Loading and other breaking V3 changes Feb 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants