From 39a9318205cab7919d5062af19a3117464163ce0 Mon Sep 17 00:00:00 2001 From: pronoy-roy-wm Date: Fri, 7 Aug 2026 13:06:22 +0530 Subject: [PATCH 1/3] Updated design guidelines to match feature flagging and update on images --- .../design-guidelines.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/docs/design-system/figma-design-to-code-plugin/design-guidelines.md b/docs/design-system/figma-design-to-code-plugin/design-guidelines.md index 83ea76d..2105130 100644 --- a/docs/design-system/figma-design-to-code-plugin/design-guidelines.md +++ b/docs/design-system/figma-design-to-code-plugin/design-guidelines.md @@ -47,6 +47,12 @@ Do not turn images into components. Unlike components, images aren't reused as r ![diagram comparing an image wrapped as a component versus an image applied as a frame fill](./assets/img/images-as-fills-diagram.svg) +## Charts + +Design to Code does not support charts yet. Any chart in your design is converted to an image in the generated code. + +Because of this, treat charts as images during annotation review. If a chart has not been annotated as **Image**, change it to Image yourself. A chart that comes through as a clean image is easier to replace with a real chart bound to real data using the WaveMaker AI Assistant once the project has been created. + ## Color Management WaveMaker Design to Code strictly follows the designer's intent, and this principle extends directly to how colors are handled in the generated code. If a designer defines a color as a local variable and applies it consistently across the design, particularly within components, that variable is preserved and translated into a corresponding CSS variable in the final code. @@ -76,3 +82,11 @@ When a section contains repeatable or related elements, group them under a meani This isn't strictly necessary, and the plugin can often still generate usable code without it. But semantic grouping goes a long way toward improving code quality, since it helps the plugin correctly infer the relationship between elements and generate more accurate, better-structured components. It's a small extra step in the design phase that can save significant time during development. ![diagram comparing loose sibling rows versus rows grouped under a meaningfully named parent frame](./assets/img/semantic-grouping-diagram.svg) + +## Optional Features + +The Design to Code plugin has two features that are turned off by default and can be enabled from its settings: **Wizards** and **Data Table**. When enabled, the plugin recognises these widgets in your design and generates the corresponding WaveMaker widgets instead of plain frames. + +They are optional because they depend on the annotations being right. Both map to WaveMaker widgets with their own structural rules — a wizard needs its steps and step content identified correctly, and a data table needs its header, rows, and cells labelled consistently. See [Data table](./annotation-glossary#data-table-web) in the annotation glossary for the structure a data table expects. When one of these annotations is wrong, the generated widget takes more work to correct than a plain frame would. + +Enable them only if you understand how WaveMaker handles these widgets and you are already reviewing every annotation, not just the ones the plugin marks as **Needs review**. If you are relying on the default review pass, leave both off. From df69eabaec4224f687b8e1cd8ee029c7dbdbfcd1 Mon Sep 17 00:00:00 2001 From: pronoy-roy-wm Date: Fri, 7 Aug 2026 14:53:40 +0530 Subject: [PATCH 2/3] Changed tone for design guideline --- .../figma-design-to-code-plugin/design-guidelines.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/design-system/figma-design-to-code-plugin/design-guidelines.md b/docs/design-system/figma-design-to-code-plugin/design-guidelines.md index 2105130..d10890e 100644 --- a/docs/design-system/figma-design-to-code-plugin/design-guidelines.md +++ b/docs/design-system/figma-design-to-code-plugin/design-guidelines.md @@ -85,8 +85,8 @@ This isn't strictly necessary, and the plugin can often still generate usable co ## Optional Features -The Design to Code plugin has two features that are turned off by default and can be enabled from its settings: **Wizards** and **Data Table**. When enabled, the plugin recognises these widgets in your design and generates the corresponding WaveMaker widgets instead of plain frames. +The plugin settings include two features that start off switched off: **Wizards** and **Data Table**. While they are off, a wizard comes through as plain frames and a data table comes through as a list. Switch them on and the plugin builds the real WaveMaker widget instead. -They are optional because they depend on the annotations being right. Both map to WaveMaker widgets with their own structural rules — a wizard needs its steps and step content identified correctly, and a data table needs its header, rows, and cells labelled consistently. See [Data table](./annotation-glossary#data-table-web) in the annotation glossary for the structure a data table expects. When one of these annotations is wrong, the generated widget takes more work to correct than a plain frame would. +They start off because wizards and tables are among the trickier things to design for. Every designer builds them a little differently, and WaveMaker has its own expectations about how the pieces fit together — which layer is a step, which row is the header, which cell sits where. Whether the generated widget turns out well comes down to those annotations being right, and you are in a far better position to judge that than the plugin is. So for now this one is left to you. -Enable them only if you understand how WaveMaker handles these widgets and you are already reviewing every annotation, not just the ones the plugin marks as **Needs review**. If you are relying on the default review pass, leave both off. +Turn them on if you already know how WaveMaker structures these widgets and you go through every annotation, not just the ones marked **Needs review**. If you would rather stick to the flagged ones, leave them off for now — you lose nothing, and you can always come back to this later. The [Data table](./annotation-glossary#data-table-web) entry in the annotation glossary is a good place to see what the plugin expects. From 0927b56c5f1a11f41564e65a64eaa59972555f58 Mon Sep 17 00:00:00 2001 From: pronoy-roy-wm Date: Fri, 7 Aug 2026 15:46:49 +0530 Subject: [PATCH 3/3] Minor change in sentence --- .../figma-design-to-code-plugin/design-guidelines.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/design-system/figma-design-to-code-plugin/design-guidelines.md b/docs/design-system/figma-design-to-code-plugin/design-guidelines.md index d10890e..d8d2d97 100644 --- a/docs/design-system/figma-design-to-code-plugin/design-guidelines.md +++ b/docs/design-system/figma-design-to-code-plugin/design-guidelines.md @@ -85,7 +85,7 @@ This isn't strictly necessary, and the plugin can often still generate usable co ## Optional Features -The plugin settings include two features that start off switched off: **Wizards** and **Data Table**. While they are off, a wizard comes through as plain frames and a data table comes through as a list. Switch them on and the plugin builds the real WaveMaker widget instead. +The plugin settings include two features that are off by default: **Wizards** and **Data Table**. While they are off, a wizard comes through as plain frames and a data table comes through as a list. Switch them on and the plugin builds the real WaveMaker widget instead. They start off because wizards and tables are among the trickier things to design for. Every designer builds them a little differently, and WaveMaker has its own expectations about how the pieces fit together — which layer is a step, which row is the header, which cell sits where. Whether the generated widget turns out well comes down to those annotations being right, and you are in a far better position to judge that than the plugin is. So for now this one is left to you.