Research how to enforce a specific views settings in grid

a24vinla commented

2026-04-13 09:04:55 +00:00

Collaborator

Certain views will need to have min/max values for height and width. We need some sort of "config" file for each view that contain these values.

Related Issues: #215
Parent Issues: #190

Certain views will need to have min/max values for height and width. We need some sort of "config" file for each view that contain these values. Related Issues: #215 Parent Issues: #190

a24vinla added the

frontEnd

research

labels

2026-04-13 09:04:55 +00:00

b24idalu was assigned by a24vinla

2026-04-13 12:48:21 +00:00

hGustavs commented

2026-04-13 13:27:17 +00:00

Owner

We need to limit this also so that it is limited per device. A smaller device may have different limits than a larger device.

What about screen rotation are these settings distinct for vertical / horizontal?

We need to limit this also so that it is limited per device. A smaller device may have different limits than a larger device. What about screen rotation are these settings distinct for vertical / horizontal?

b24idalu commented

2026-04-13 16:40:02 +00:00

Collaborator

To limit sizes depending on devices, one usually uses "lg,md,sm,xs,xxs". Here is a simple codesnippet that can help decide sizes. Width is a variable already initiated in the code. When rotating for example a phone, the width will become the height which can make it more difficult. To solve this, there exists a resize event that listens for rotations or other resizing.

  const getScreenSize = (width) => {
    if (width >= 1200) return "lg";
    if (width >= 996) return "md";
    if (width >= 768) return "sm";
    if (width >= 480) return "xs";
    return "xxs";
  };

Going from there, right now cards' positions are determined by the key. One solution could be to create a new dictionary
containing the different card names and their min/max and then combining them to the already set sizes of cards. This can be done by doing "...temperaturView[width]" in the layout field; i.e.: const layout=[{i: "2", x: 1, y: 2, w: 1, h: 2, ...temperaturView[width]}].

  temperatureView: [
      lg: { maxW: 6, minW: 4 },
      md: { maxW: 5, minW: 4 },
      sm: { maxW: 3, minH: 3 },
      xs: { maxW: 2, maxH: 3 },
      xxs: { maxW: 2, minH: 2 }
    ]

In short: one can set max/min height/width through the layout already, when adding a new card one can check its type and add corresponding value from a dictionary.

To limit sizes depending on devices, one usually uses "lg,md,sm,xs,xxs". Here is a simple codesnippet that can help decide sizes. Width is a variable already initiated in the code. When rotating for example a phone, the width will become the height which can make it more difficult. To solve this, there exists a resize event that listens for rotations or other resizing. ``` const getScreenSize = (width) => { if (width >= 1200) return "lg"; if (width >= 996) return "md"; if (width >= 768) return "sm"; if (width >= 480) return "xs"; return "xxs"; }; ``` Going from there, right now cards' positions are determined by the key. One solution could be to create a new dictionary containing the different card names and their min/max and then combining them to the already set sizes of cards. This can be done by doing "...temperaturView[width]" in the layout field; i.e.: const layout=[{i: "2", x: 1, y: 2, w: 1, h: 2, ...temperaturView[width]}]. ``` temperatureView: [ lg: { maxW: 6, minW: 4 }, md: { maxW: 5, minW: 4 }, sm: { maxW: 3, minH: 3 }, xs: { maxW: 2, maxH: 3 }, xxs: { maxW: 2, minH: 2 } ] ``` In short: one can set max/min height/width through the layout already, when adding a new card one can check its type and add corresponding value from a dictionary.

b24idalu added the

needs review

label

2026-04-13 16:41:10 +00:00

b24krila was assigned by b24johka

2026-04-14 09:47:18 +00:00

b24krila commented

2026-04-14 10:30:37 +00:00

Collaborator

The idea makes sense and is aligned with how responsive grids are designed. With breakpoints such as lg/md/sm to decide the different min/max sizes per view is a solid approach also the dictionary-based configuration per view is also a good idea.

That being said I have some questions.

You say "one can set max/min height/width through the layout already, when adding a new card one can check its type and add corresponding value from a dictionary" does that mean that the developers are "responsible" for manually selecting the correct breakpoint rules and applying them every time a layout item is created? or will we have a "centralized" config that should handle this automatically.

Basically I am trying to understand how the responsibility lives here, because if done manually then that could lead to issues over time by missing or implementing inconsistently when creating new or modifying existing views. On the other hand having a centralized config to handle it would make the system more robust since rules would always be applied consistently with no regard with who created or updated a layout.

Otherwise this research is well done.

The idea makes sense and is aligned with how responsive grids are designed. With breakpoints such as lg/md/sm to decide the different min/max sizes per view is a solid approach also the dictionary-based configuration per view is also a good idea. That being said I have some questions. You say "one can set max/min height/width through the layout already, when adding a new card one can check its type and add corresponding value from a dictionary" does that mean that the developers are "responsible" for manually selecting the correct breakpoint rules and applying them every time a layout item is created? or will we have a "centralized" config that should handle this automatically. Basically I am trying to understand how the responsibility lives here, because if done manually then that could lead to issues over time by missing or implementing inconsistently when creating new or modifying existing views. On the other hand having a centralized config to handle it would make the system more robust since rules would always be applied consistently with no regard with who created or updated a layout. Otherwise this research is well done.

b24krila removed the

needs review

label

2026-04-14 10:30:44 +00:00

b24idalu commented

2026-04-14 11:11:11 +00:00

Collaborator

Since views can have different sizes, my suggestion is that we create a default config that will apply to all views, unless the developers set their own. If they set their own, it should follow a set of rules that make it reusable by other developers. This means that other developers can then deem if they want the default or follow another config. The rules should be able to help with consistency

b24idalu added the

needs review

label

2026-04-14 11:17:44 +00:00

b24krila commented

2026-04-14 11:45:22 +00:00

Collaborator

Thanks for the clarification.

The approach seems reasonable and it should help avoid inconsistencies atleast when compared to a fully manual configuration.

It might be a good idea to include this in a wiki page to have an easy access to the defined rules and conventions, so all the developers have access to a single wiki page to refer to.

This could also be a good place to go a little more into detail about how the custom configs should be structured what is valid or invalid and how the constraints are expected to behave. With a clear wiki page to turn to it would also be easier to maintain the consistency over the system as it evolves.

Thanks for the clarification. The approach seems reasonable and it should help avoid inconsistencies atleast when compared to a fully manual configuration. It might be a good idea to include this in a wiki page to have an easy access to the defined rules and conventions, so all the developers have access to a single wiki page to refer to. This could also be a good place to go a little more into detail about how the custom configs should be structured what is valid or invalid and how the constraints are expected to behave. With a clear wiki page to turn to it would also be easier to maintain the consistency over the system as it evolves.

b24krila removed the

needs review

label

2026-04-14 11:45:27 +00:00

b24idalu added the

reviewed

label

2026-04-14 11:46:28 +00:00

a24vinla referenced this issue

2026-04-16 06:49:13 +00:00

Specific settings for views #330