Wrong calculation of breakpoints

[oweitman]

ioBroker.admin/packages/jsonConfig/src/JsonConfigComponent/ConfigTable.tsx

Line 1555 in c854d42

getCurrentBreakpoint(): 'xs' | 'sm' | 'md' | 'lg' | 'xl' {

https://github.com/oweitman/ioBroker.admin/blob/79bfa9e5b08535770bfdabc1fb7902de2eadde6c/packages/jsonConfig/src/JsonConfigComponent/ConfigTable.tsx#L1097

this.state.width is the width of the actual element and not the width of the screen.

the original proposed function

    iobUseMediaQuery(key: any): boolean {
        let query = this.props.theme.breakpoints.only(key);
        query = query.replace(/^@media( ?)/m, '');
        return window.matchMedia(query).matches;
    }

is taken from a hook of the next mui react version 6
https://mui.com/material-ui/react-use-media-query/
https://github.com/mui/material-ui/blob/44ba5f75ed60074892ef135fa6283a28af93a74c/packages/mui-system/src/useMediaQuery/useMediaQuery.ts

[GermanBluefox]

Important is the width of the panel and not of the screen. We use JsonConfig in Dialogs too and in this case it is important to know the width of the dialog window.

[oweitman]

for example i set a 3 column table with md = 6
then this algorithm leads to recognize the width as too small and show the card layout

if no widths are defined everything is ok,
but sometimes this breaks if the dev already defined a with

for eaxample see adapter openliga in version 1.8.0 (in v1.8.1 i enlarged the with as a workaround)
see the 1.8.0 version of jsonConfig
https://github.com/oweitman/ioBroker.openligadb/blame/81f1f11d1196c8ed65a5e69754b9d4125b1f8ed6/admin/jsonConfig.json#L23-L32

[Apollon77]

Hm… but if the dev defined a smaller width then this width is the relevant one for the question how to display the table and their elements inside this element. Right? Or what do I miss?

[simatec]

I think @GermanBluefox approach makes perfect sense. Problems often arise, especially with displays in dialogs. The current solution solves all problems, including tabs in popups such as in the Matter Adapter.

[oweitman]

mui react defines breakpoints in terms of the screen width of a device/browser.
here the width of a jsonconfig widget is calculated and used in the same notation. this could confuse users.

as an example: the openligadb table is defined at md with 6. the screen width is md. however, the calculation from bluefox results in sx. this would mean that a user has to specify the usecardfor setting at md with sx

my original calculation and assumption is that the calculation results in the actual screen width, then compares it with the specification with usecardfor and applies it accordingly. if the dev then provides a specification for the breakpoint, you are actually flexible, as the following construct also works. screen width is md, md is 4 and usecardfor is also on md, then you are able to use the card view even with wider screens.

I don't really understand the advantages of dialogs, tabs, etc., since this discussion is only about configTable, or have I not understood something?

i add a link the the bluefox function to clarify the relation to the code

[GermanBluefox]

Was für eine Rolle spielt die Breite von Display (Browserfenster) wenn ich meine Tabelle in einem schmalen Fenster zeige?? Ich verstehe die Logik nicht.
Browser kann 5000px sein, aber was bring es mir, wenn mein Dialogfenster 600px ist? Ich kann sowieso nicht die Tabelle mit 20 Zellen in 600px reinpuschen? In 5000px aber schon

[oweitman]

Grundsätzlich so wie du es sagst ist es schon richtig.
Aber dann dürfen wir auch nicht die Breakpoint logik verwenden, da diese sich schon eindeutig auf Devicegröße bezieht.

Die ursprüngliche herangehensweise war, das Tabellenproblem für kleine/schmale Displays zu optimieren,
ohne das Nutzer da groß etwas machen müssen (zumindest wäre das für einige Adapter nicht zeitnah passiert)
Daher habe ich folgende Annahmen getroffen, so das das Table Element automatisch in die Card-Ansicht umschaltet:
Bildschirmgröße ist SX oder SM und die Tabelle hat mehr wie 3 Spalten.
Darüber hinaus noch das Attribut useCardFor mit der Angabe der Breakpoints für Devs, die dieses Feature bewusst nutzen wollen.

Durch die Berechnung der Elementbreite in deiner Funktion haben wir nun ein Bruch der Logik, da du nun die breakpoints-Notationm (wie gesagt bezieht die sich auf Gerätegreite) mit Elementbreite gleich setzt. Das könnte meiner Meinung nach die Devs verwirren. Wenn wir bei der Verwendung von Elementbreite bleiben, sollte man sich da etwas anderes überlegen.

Aber wir können es ja mal laufen lassen und sehen ob hier fragen aufkommen. Evtl vermute ich hier zu viel.
Andernfalls muss es halt durch Dokumentation ergänzt werden.