can you support flex-wrap and hug content( without fixed width and height)

[kaneruan]

can you support flex-wrap and hug content( without fixed width and height)

[bernaferrari]

Yes, I just need to figure out the new API.

[davestewart]

Hey, have the same issue here.

Seems like this line could just be:

  if (typeof size.width === "number" && (node as FrameNode).layoutSizingHorizontal === "FIXED") {

[bernaferrari]

if it works well feel free to make a PR :P but it should be "layoutSizingHorizontal" in node && node.layoutSizingHorizontal, FrameNode is too restrictive. InstanceNode, ComponentNode, other things might have it too.

[davestewart]

Hey @bernaferrari, @kaneruan ...

I'm looking at this, this morning, and continuing the discussion here (vs the previous PR) so others can contribute.

It seems that to better-support Flexbox and Tailwind that some more work is going to need to be done.

Flexbox / sizing

Currently the HTML and Tailwind exports do not correctly support the various fixed/fill combinations.

Here, the boxes have fixed widths:

Yet, they export with flexbox as scaled to fit (normal flexbox behaviour as I understand it):

They should only do this if set to fill container:

Setting shrink-0 would solve this (may also need to check parent resizing mode, not sure yet):

And would also work in Tailwind:

https://play.tailwindcss.com/6I3tJVO5vv

Flexbox / axis

To achieve wrapping, I'll need to tweak the align-items / align-content CSS properties when wrapping is on, but I seem to have this working:

In summary

If everyone is happy with this, I'll implement the following:

• shrink-0 for fixed-size content (not needed when wrapping)
• align-items / align-content for wrapped content

Obviously flexbox is a fairly complex beast so I'll do my best to build on top of what has already been done, but also open to input / tips as I start to write code.

LMK, thanks.

[davestewart]

@bernaferrari – what is the optimizeLayout flag supposed to do?

It seems to just prefer inferredAutoLayout.* to node.* in the functions it's used it.

I see this is a user checkbox, vs something used internally.

I understand that the property is a kind of amalgamation of node properties. I've run some test code and it appears that the two are always in sync.

Does it make a difference to the code output?

Am I missing the intent?

[bernaferrari]

optimize layout is figma trying to infer the AutoLayout for you. If you have a frame with two rectangles, it is going to pretend there is an AutoLayout. So the user can be "I prefer the system to figure out AutoLayout for me" or "I'll do myself". With the new "magic AutoLayout" system they introduced last week, it will be super easy for people to make AutoLayout everywhere, so I guess inferred auto layout will be less needed.

…

On Thu, Jul 4, 2024, 07:39 Dave Stewart ***@***.***> wrote: @bernaferrari <https://github.com/bernaferrari> – what is the optimizeLayout flag supposed to do? It seems to just prefer inferredAutoLayout.* to node.* in the functions it's used it. I see this is a user checkbox, vs something used internally. I understand that the property <https://www.figma.com/plugin-docs/api/FrameNode/#inferredautolayout> is a kind of amalgamation of node properties. I've run some test code and it appears that the two are always in sync. Does it make a difference to the code output? Am I missing the intent? — Reply to this email directly, view it on GitHub <#82 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACVXFITKFGMZAONIFZK643ZKUQ55AVCNFSM6AAAAABKH4SJFGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBYGY2TSMZWGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[davestewart]

Hey @bernaferrari.

This is probably just me not understanding optimize layout, but can you help me understand something?

I thought for a while I may have discovered a possible issue with commonSortChildrenWhenInferredAutoLayout() when layoutWrap is set to "WRAP" – but I might be mistaken.

Because the algorithm sorts on x position when layoutMode is "HORIZONTAL" wrapping elements will be sorted out of order.

Optimise layout is off, layers render in order (see code):

Optimise layout is on, layers render out of order (see code) because they are sorted in x:

However, the container pictured above already has Figma auto-layout on (set to HORIZONTAL) so should it not just return the existing children in order?

https://github.com/bernaferrari/FigmaToCode/blob/main/packages/backend/src/common/commonChildrenOrder.ts#L8

  // add this line
  if ('layoutMode' in node && node.layoutMode && node.layoutMode !== 'NONE') {
    return node.children
  }

I appreciate it might have been a while since you looked at this code, but can you confirm?

Thanks!

[bernaferrari]

inferred doesn't return the childrens ordered, so I try to guess their order :P

[davestewart]

Sure, but when an object already has auto-layout, ordering does not need to be guessed.

My point is, this function is being called from <platform>Frame() even when auto-layout is on (and I don't think it should be).

Am I wrong?

[bernaferrari]

oh, interesting. Yeah, you found a bug!!

[davestewart]

OK! Thanks for confirming. I'll fix it along with the wrapping implementation.

[davestewart]

So I finally figured out what inferred auto layout is 😅

Any layout for which you could click "Auto Layout" and the layout would be rendered exactly the same once auto-layout properties such as gap, padding and alignment were applied.

green: layout would be the same after auto-layout applied, red: layout would not be the same

Not sure why they don't say this in the docs!

[bernaferrari]

Yes. I thought I was clear, sorry.

…

On Tue, Jul 16, 2024, 21:07 Dave Stewart ***@***.***> wrote: So I finally figured out what *inferred* auto layout is 😅 Any layout for which you could click "Auto Layout" and the layout would be rendered *exactly the same* once auto-layout properties such as gap, padding and alignment were applied. CleanShot.2024-07-17.at.01.05.14.png (view on web) <https://github.com/user-attachments/assets/27247894-0c9f-4bb4-97b0-148846247522> Not sure why they don't say this in the docs! — Reply to this email directly, view it on GitHub <#82 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACVXFIEZ3435CRTFWVDOPTZMWYVDAVCNFSM6AAAAABKH4SJFGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZSGA2DAMRYGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[davestewart]

No worries. Thanks for helping get up to speed on the Figma API and answering all my questions!

[davestewart]

Interestingly, inferredAutoLayout is null for potentially wrapped elements, even when clicking the auto-layout button correctly applies wrap to the layout:

Suspect the heuristics only take into account the general offsets and padding, etc.

[davestewart]

FWIW, some of the UI options could be disabled if they are not relevant:

• "Optimize Layout" – if there are no inferredAutoLayout nodes
• "Round Values" and "Round Colors" – if no [] or / characters found in classes
• "Custom Colors" – if no color variable used

[bernaferrari]

if I enable inferredAutoLayout, click in a layout without, then click in a layout with it, will the option work?

If it is documented somewhere that they are disabled because there is nothing, I guess it is fine. Or could have some sort of section like "unused on current selection:"

[davestewart]

Ah, I see what you mean.

I suppose I was thinking about making it clearer for users who might click the options (when irrelevant) and wonder why they were not having any effect.

Not a big deal, just a nice-to-have. Can save it for later!

[bernaferrari]

we can have that disabled, as long as it is clear for users (even if irrelevant). Another way is add on the tooltip: "current selection doesn't make use of color variables". with a check or X. Could be useful for people.

[davestewart]

Will add a feature request issue.