-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More flexible collection management #461
Comments
I have experimented with this a bit: https://gist.github.com/tek/d427c0fd9f8650892d3c469b63b55175 I also tried to use https://gist.github.com/tek/1ea3d43127d5f17fafbfd139f169b269 |
If you’re using reflex-dom you can control order with css via |
This looks interesting, but I’m not quite sure what it does. What is
Unfortunately, I’m not using flexbox. And even if I were, this wouldn’t solve all my problems, since it will still always render in a list. |
The type of the update elements in the |
Currently Reflex supports managing collections of widgets via the various functions in
Reflex.Collection
, roughly:These work well enough for simple interfaces. Unfortunately, they have a major problem: they are all list functions. That is, Reflex currently renders the
m a
widgets by running them sequentially in the order specified by the map keys; there is no way to render them in any other order. Accordingly, it can be difficult to dynamically manage tables or any other sort of widget layout.Additionally, these functions make it difficult to do anything aside from simply adding widgets to the end and removing widgets from anywhere. Inserting an element in the middle of a map is difficult, for instance, and swapping two widgets is completely impossible.
In theory, I should be able to write a replacement function myself which does what I want. In practice, this requires dealing with
Adjustable
, a typeclass with practically no documentation whatsoever (#418), as well as various other corners of the library with just as little documentation (e.g.Incremental
). I only even know that much from reading the definition oflistWithKey
. Basic widget manipulation should not require reading the source code of the GUI library!Accordingly, it would be nice to have a new, fully general function for collection management, one which supports the manipulations I mentioned above. I suggest something like the following:
The idea here would be that the final parameter provides a method for collecting each individual widget into a larger widget, allowing control of sequencing etc. But I’m not sure if this would work as is.
The text was updated successfully, but these errors were encountered: