Maybe I’m missing something obvious, or there’s a concept I’m not getting, but I’m thinking I should be able to bind a component property to the container or view’s current breakpoint value. In this example I want to change the vertical alignment of the text in a label based on which breakpoint is active. How can I achieve this?
Thanks!
Unfortunately, due to the properties we provide visibility into, this is not possible.
Breakpoints use the logic “At widths above X px display content like this.”
Breakpoints do not have any properties exposed in the Designer that would allow you to ascertain which breakpoint is currently being used, nor what the current dimensions of the viewport are. Exposing viewport dimensions is something we’re planning on doing in upcoming versions, but it will be some time before it is ready.
If you’d like to lobby for this feature, you could provide a new post in the ideas forum in an attempt to provide better visibility of the need for such a feature.
If and when this information is exposed, you can produce infinite loops if used to change the layout within the selected breakpoint. An alignment change shouldn’t change that element’s size, but I suspect many people wouldn’t limit themselves to harmless (dimensionally identical) changes.
Correct, which is why we would most likely only supply viewport dimensions, and NOT breakpoint information.
Right. Programmatic Darwinism. I can think of many good cases to change individual component visual properties with breakpoint triggers. So I hope it can be added.
As we previously mentioned in this thread, providing insight into Breakpoint properties is inherently dangerous as it invites (pseudo-code)
self.page.breakPointInUse = self.view.props.breakpoints[indexIWant]
when really it’s not on the View or code to determine which breakpoint is in use; that should fall entirely on the backend code.
Viewport dimensions on the other hand are absolutely something a user might like to know about. Whether we should allow for writing back to them is something else entirely, so in what way do we provide those values? They’re independent to the session, so session properties seems the logical choice, but if they’re read-only we need to lock them down, which is something we need to look into.
Sounds great, all I want to accomplish is some extra control over component properties based on the size and orientation of the display in use. However that gets implemented is great for me. I don’t know what pseudo-code is (maybe I don’t want to know, as I likely do a lot of it), and you guys all have much better perspectives on how us less professional coders might mess up when using the platform. We still have access to scripting that can cause (when poorly implemented) infinite looping and thread lockups, so I guess you still trust the less elite masses to some degree. 
Cheers.
Pseudo-code is generally understood as “here’s some stuff that looks like real code, but really it’s just meant to convey the logic and therefore shouldn’t be taken as gospel because it’d probably fail if you tried to execute it”.
Yes, we try to leave everything as open as we can, but infinite loops in a script are one issue (you can pretty easily find them and they’ll only lock up one thread anyway) - infinite loops caused by implementation are a much bigger problem, because your script could be a simple one-liner (like the previous example), but the way it’s used could create an infinite loop which might lock up multiple threads and inhibit user interaction.
Anyway, it looks like some other users have finally created a formal request on the ideas forum
I came across this old topic while searching for a possibility to get the current breakpoint or view size information. I encountered multiple situations where I missed this information. Unfortunately the viewport size made available in recent releases does only provide very limited possibilities.
Imagine a flex repeater or container with child views which have a variable height. E.g. on smaller screens they align their elements vertically, on bigger screens horizontally. The container / repeater is set to column so that the child views are stacked vertically.
To make that setup scale properly we need to set a minimum height for the elements in the repeater (basis property).
This size is variable and depends on the currently active break point of the child views (and therefore indirectly on the size of the repeater itself). None of this information is available.
The viewport which has been exposed in current versions is not useful in this case, because the repeater / container size is different from the global viewport size.
As stated above, the reason for not exposing the breakpoints is because it can be misused to create infinite loops.
I do not really see this as an argument, since there are many other ways for a programmers to create infinite loops if they are not aware of what they are doing. But it would not even be necessary to actively influence the breakpoints (which does not make sense).
Only having read access to this information would already be extremely beneficial to resolve a lot of challenges which are barely solvable right now. Knowing the current size of a view / component would also solve the problem.
Therefore I have created another feature Idea. Please upvote if you also think that this feature could be handy.
I have an issue with this
I have 2 flex repeater objects that react to the screensize using the columns container
on my phone it looks like this:
Maybe you can get the column container to work for you, but I gave up on it a long time ago, in part due to this reason and due to it being so hard to configure and move components around intuitively.
After a 5min play, what about using a flex with wrap set? not sure if there's a better way, but in the template on the text group and the buttons group I set the heights manually so that I could use an auto basis in when I embedded them into a flex container to allow them to shrink and expand when the width forces them to wrap...
Dynamic height flex rows.zip (9.7 KB)
Edit: I added the gap property to all the flexes, I didn't redo the screencapture though...
This is what gap does, it adds fixed gaps between components in a flex:
So it doesn't look like this:
