I have a vertical stack and I can't seem to pull in other stacks in a specific order. Whenever I drag the stack to a certain position it doesn't stay there. Please have a look at this video:
Interestingly renaming the stacks within stack 15 did work for 2 components and they visually got sorted in alphabetical order. But for the 3rd component it didn't work.
Hi @boernard Thanks for reporting this! The recording is super helpful. Any chance you could also share an app json with us (feel free to post here or DM)?
I haven't been able to reproduce this bug for our team, but I'm hoping a json export can narrow down the issue
One really great feature would be to actually drag and drop the components within the stack in the component tree view on the left side.
Since a stack is pureliy ordinal it would make things so much easier because the drag & drop targets are soo hard to get as soon as you have a stack within a stack. I will post this in feature requests again
I've been noticing problems with the reordering items in stacks over (roughly) the last week, across several projects (work project, personal project, and my wife's work project -- all on different laptops and under different accounts.) The issues are varied but I suspect they're all symptoms of a same problem:
dragging an item inside a stack may show a caret for where the item will drop, but once released, it stays where it previously was
renaming items inside a stack may cause them to move (usually to the end of the stack, but not always -- in one case, it looked like the items were actively reordered to become alphabetized by their component names)
some items in a stack may be completely immovable (you don't even get the caret when attempting to drag)
cutting/pasting items in a stack sometimes works to force them to the end of the stack, and other times items will paste back to their original ordinal position
I've got a reproducible example of symptom 3, so I'll start with that.
In this example, I created a stacked container, and dropped a few text items in it -- they were orderable. I renamed them, nothing weird happened. I then added some collapsible containers to the list -- and they refuse to move. I can move the text items around (same container), but not these two items. In this case, renaming and cutting/pasting do not reproduce symptoms 2 and 4, sorry.
What gave me the idea to try this? I noticed in one of my real projects, when exported to ZIP format, that some of my immovable objects were the ones "included by reference" instead of inline, i.e. I would see <Include src="./subobjectname.rsx" /> and wondered if certain object types (like collapsible containers) might be more likely to cause that to happen, and by extension cause the re-ordering problem. However, my quick little example reproduces the issue without those nested containers being pushed into their own separate rsx files, so that's not the cause, I just got lucky on reproducing.
Looking at the positions JSON file, I don't see anything weird about the collapsible containers vs. the text items that are their peers, yet they behave differently in terms of reordering.
If I can reproduce the other issues mentioned above (or maybe someone else can?), I'll post JSON files. scratchpad.json (18.6 KB)
@Tess
I've extracted a subset of a personal project -- it was originally part of a modal frame, but the dragging/rearranging problem persists even when these particular controls are copied into a new scratchpad app by themselves.
What I was seeing with this example:
the input fields and tag fields along the bottom are part of a stack; you can attempt to re-arrange them, but you'll have symptom 1 where you see the drop-spot, but the control refuses to actually move
in the repeatable (grid) at the top, each of the items is a stack (icon, spacer, text, spacer); attempting to re-arrange items inside the template item will similarly tease you with a caret, then refuse to actually move
I was getting around it by cutting/pasting objects, where each time I pasted, items would go to the end of the stack rather than returning to their previous ordinal position, and with enough cutting/pasting I could get things into the desired order reproduceDragProblem.json (19.8 KB)
Thanks for the update! I'll take a look and share the findings with our team internally. Definitely appreciate the time you took to narrow this down a bit!
I'm experiencing this issue as well. There's no way to order components in a stacked container. If I try to cut the component, and 'paste below' it pastes it wherever. There's also no way to move the component to a different position. Very frustrating as it makes the stacked component feature virtually useless.
Apologies for the issue. We do have a feature request for programmatically adding in ways to manipulate the order of components in a stacked container.
I can add +1 to those tickets for you. In the meantime, is it not possible for you to rearrange the components in the stacked container via drag-and dropping them?
Also you mentioned two points, one being order and one being 'position'. For stacked containers the order will be the main point of controlling how they fit into available space relative to other components inside the parent container.
To have greater control over sizing the child components and where exactly they fit into the parent container, you would have greater control in a regular container that is not stacking its children components.
I have no idea why I'm unable to rearrange components the way that you've done here. While in stacked mode, moving components isn't working in my application. only way I've found to rearrange items the way I want them to, is to remove everything from the container then cut and paste inside the container in the order by which I want them.
Ah ok that is interesting, I am very curious why the drag and drop functionality isn't working on your end
You may need to switch the container from Layout:Display:'Stack' to 'Grid' as it looks like this allows for the canvas to better move and control the layout of components!
I would recommend switching to Grid, making the parent Stack component really big, getting all the components inside and drag them into the correct order, then switch over to 'Stack' mode.
Let me know if even with Grid mode that you are unable to drag and drop. If you can share a video that might be helpful as well for troubleshooting!
I have this issue in spades. I've tried switching back and forth between Grid, vertical stack, and horizontal stack with unreliable results. I've found that increasing the padding between elements sometimes helps insofar as it makes it easier to grab components and creates larger drop zones, but even when things look right before dropping the reorder doesn't take. The only true solution is to create a new container, set it as a stack, and then drop components into it in the order you need them. Reordering an existing container after will work until I delete any other component from the app. After that, reordering is a total crapshoot.
For what it's worth, I think one reason you guys can't reproduce this is because it only seems to happen on larger apps, and even then only after deletions. Tons of stuff that bugs out on me in production works just fine in skeleton apps.
Yup. In smaller apps reordering is easier. Switching to grid doesn't do much, because as soon as I switch back to stack, it reorders itself again. I did try this padding thing. This seems to work better than most other options! Thanks for that!
It is tricky when issues occur do not on skeleton apps but only when a certain threshold of app size is encountered.
If you or @Eric_Johnson1 have any videos of the order being changed after expanding the container to maximize drop zone and placing them in, that would be helpful to share with the engineering team.
That is interesting to hear that deleting components will then cause the behavior to change afterwards
I ran into the issue in a larger app, but copy-pasting the affected container into a scratchpad app preserved the issue – so while it might initially appear only in larger apps (or there’s a selection bias by which only builders of larger apps will commonly run into this AND want to report the issue), it can be reproduced in smaller ones by just extracting the affected chunks … and that means there’s something stateful about the problem, some property of those controls that gets carried over when copy/pasting between apps. It’s not merely a contextual/size issue. (see my json, above, from May 7.)