As soon as I make something into a component, the option to set a flex size goes away. I have to wrap it in another non-component container in order to specify a flex size.
I guess this is a known issue? https://talk.subformapp.com/t/why-are-layout-properties-like-width-height-margin-etc-not-part-of-the-class-properties/777
I'd advocate for finding some sort of solution here, the current implementation just feels broken. Even if the layout fields were usable but didn't propogate into the component, I'd at least be able to set them without having to duplicate a bunch of containers. I'd rather just have it be part of the component though.
What's the use case for multiple inheritance? As it sounds like that's part of the reason this doesn't work as I'd expect.
Or am I getting confused here? Are classes and components different things?
The whole point of components is that they can have multiple instances.
So it's possible to get into a situation where one component instance is under a parent that has vertical flex and another instance is under a parent that has horizontal flex.
We couldn't figure out a way for the shared, component-wide layout to handle this situation, so we just took out flex entirely.
If you need flex, you can do a few things:
Use containers, and set the component instance to have 100% width/height so that it takes the size of the container. (Or just 100% in the direction you want to stretch, and do whatever you want for the size in the cross direction --- depends what you are trying to build.)
Set an instance layout override by clicking the link icon in the "Dimensions / Positioning" header. This lets you and set a layout (including flex) that is specific to the instance you have selected. The downside of this is, of course, that it's specific to the instance you have selected, so it won't share layout properties with other instances of the component.
Ok. I understand your decision here, but I'd argue that it's kind of an edge case. I think It'd be a shame to hamper the expressiveness of the layout engine and force people into clunky workarounds just to avoid a potential situation they may never get in to. Especially as it's not initially obvious why this doesn't work.
This rolls into the larger discussion on the layout engine going on right now. If you do go down the route of allowing designers to get into ambiguous situations and then deciding how to resolve them later, this would be a good candidate for that sort of workflow.
The two primary solutions we came up with are edge cases / confusing in a way:
The current behavior of disabling flex for components is surprising, and the solution (using instance overrides) is hard to discover.
Setting flex separately from width/height obscures that flex is what's driving the dimension rather than the concrete width/height value. And you still have the problem of what happens when you want one instance to be, say, width flexed, and another to have a concrete set width.
I'd love if you could think a bit more and offer some possible solutions that Ryan and I may have overlooked.
In particular, do you think it's useful that flex is treated as width/height value?
Or would it be better to treat flex as a separate value that applies to both width and height (depending on the configuration of the parent)?
Thoughts on layout