vlk-studio / figma-to-morfeo Goto Github PK

Describe the bug
The DelteButton component have an hardcoded tooltip, so regardless of where is used, it shows ever the same message.

To Reproduce
Steps to reproduce the behavior:

1. Run the widget
2. Simply hover on a Color slice

Expected behavior
On Colors, and later on Fonts and so on, the message should be different since they are not related to the Box component. We should create an tooltip enum on constants.ts and pass it to each delete button separately.

Describe the solution you'd like
Would be great to define and enforce some linting/format rules using eslint & prettier.

We can use also lint-staged to run a prettier --write script

Is your feature request related to a problem? Please describe.
At the moment we can add some slices but it's not possible yet to export the Morfeo theme. We need to add this feature

The "download" button itself could be added using property menu. This button should parse the current state and trigger UI plugin (hided) to allow trigger an actual download. To trigger the plugin, we need to add a ui.html file and the following setting to manifest.json. At this point we can just trigger a Promise with the folllowing:

figma.showUI(__html__, { visible: false });

Is your feature request related to a problem? Please describe.
We are currently missing all the font-related slices, such as:

• font
• font weights
• font sizes
• line heights
• letter spacings

Now, on Figma is possible to save Text Styles on the library, but not the properties mentioned above.
A Text style is basically the combination of all font properties, so we should find a way to create Text Styles on the widget (making sure every property is consistent with the related slice)

Describe the solution you'd like
The best option is probably to add all slices on the widget + a Text Style section. Then the Text Style section will provide some dropdown, so it's quite easy to enforce the consistency of values and also pretty straightforward for the widget to save such Text Style on the library.

Edge cases to consider:
If the user will edit a text style directly on the library, the widget won't notice. So in this case we should go with the same solution used for the colors (when a add/edit event is triggered, sync the library using widget as source of truth)

Describe alternatives you've considered
An alternative could be to use the library as source of truth, making the slices on the widget read-only (values calculated from text styles). But I don't really think it's the best, since as we said editing the library does't trigger any event on the widget, forcing us to poll to listen for changes or providing a button to manually update.

Is your feature request related to a problem? Please describe.
As per #25 we're dropping all slices non-supported by variables. So we want also to convert the remaining (radii, colors) to use the variables

Describe the solution you'd like
When the plugin is initialised it should:

• check if there's a collection named "Morfeo tokens"
• if so, should check if there are variables (only scoped to radii) and use them to set radii (or create some defaults otherwise)
• if not, should create such collection and create the defaults

Same thing for colors

Is your feature request related to a problem? Please describe.
This issue is related to the following comment on #17

Basically as suggested by @lucacacciarru we should consider if we want to add some default values anyway

Describe the solution you'd like
Basically IMO it's easier to add the defaults just if the library have not valid values for two reasons:

• in a already-existing project, most likely the user want to see his values, so will be forced to delete the defaults if don't need them
• if we add the defaults anyway, resetting the widget / deleting it and restarting will case duplications on the library (so it'll require a pretty heavy check to understand if the defaults are already in the library)

Describe alternatives you've considered
Probably the cleanest option could be to ask the user if he wants the default values or not, through some config (or maybe even a "generate defaults" button)

Let's discuss it here to find the best solution. Comment from @mauroerta is very welcome ❤️

Is your feature request related to a problem? Please describe.
The SVG component exposed by figma widget accept a src prop which should contain an svg string of the form "<svg .... />".
I don't really like passing it directly as a string

Describe the solution you'd like
If possible I'd prefer to import a .svg file and use it a src (need to investigate if it's possible to do it using a svg loader or similar)

Would be also nice to set up a Icon component which takes a name prop and render the related SVG

Describe alternatives you've considered
If is not possible or too tricky to set up a svg loader as proposed above, a simpler solution is to save all svg strings in a map object

Is your feature request related to a problem? Please describe.
Currently we are using as id of items stored on our state the ID of the first instance created. It's not an huge problem but it's confusing since we often run in the following situation:

const instance = figma.createComponent() // returns something like: { id: 'AA' ... }
const newStateItem = {
  id: instance.id,
  name: '...'
  refIds: [instance.id]
}

Describe the solution you'd like
A nice solution could be to use libraries such as uuid to be sure the id of the state is not equal as one instance

example:

const instance = figma.createComponent() // returns something like: { id: 'AA' ... }
const newStateItem = {
  id: uuid(),
  name: '...'
  refIds: [instance.id]
}

Is your feature request related to a problem? Please describe.
Right now the widget support just Radii slices. We need to add more slices, such as Border width

Is your feature request related to a problem? Please describe.
Figma recented introduced variables, and looks like it's exactly what we need to create/maintain design tokens. Unfortunately, not all slices are currently supported: border radius, spacings (paddings, item spacings), colors e sizes (width, height, maxWidth, maxHeight). So we need to drop (for the moment) all non-supported features, since Figma will introduce them later.

Additional context
Here more info about the current and upcoming Figma features: beta features

Is your feature request related to a problem? Please describe.
Color slice still has to be added. This slice it's quite different from existing slices because it does not relate to Box component. Instead, it has to do with Figma' library so we should consider the following:

When the widget is initialised the first time, we should:

• scan the solid colours saved on the library
• if any, use them to populate the state
• if not, create some default, save them on the library and on the state

When we add a new color slice:

• we should create a new color style (on the library)
• add it to the state

When a color slice is edited (name/value):

• edit it on the state
• get the related style on the library and update there as well

Potential problems
Since the library is external to the widget, editing/adding/deleting something from the library does not trigger any event on the widget. And that's where the "problem" comes. Let's consider following cases:

• the user has 3 colours on the widget, but he delete one of them from the library (so the widget still show 3, the library 2)
• he edit a name or a value on the widget

At this point there are two main options:

1. just edit the value requested, and if the related style on the library is not found, just add it (so without considering the other values)
2. no matter which color slice is updated, when such event occurs, make sure to sync the library with the state (probably using the widget state as source of truth)

Personally I would go with 2. but maybe it's better to discuss and take care of such edge cases on a separate issue.

Describe the bug
If the BOX component is deleted, but the state of the widget is already there, everything is messed up (since on the state there are the references to BOX instances)

To Reproduce
Steps to reproduce the behavior:

1. Run the widget
2. Delete the BOX component
3. Add / edit / delete a slice

Expected behavior
3 different use cases:
a. The Box is deleted and the user add a new slice -> the widget should:

1. create a new box component with the variants already in the state
2. update the refIds on the existing variants (since the refIds are referring to non-existent instances)
3. add the new variant

b. The Box is deleted and the user edit a existing slice -> the widget should:

1. edit the variant just on the state
2. create a new box component with the variants in the state
3. update the refIds on the existing variants (since the refIds are referring to non-existent instances)

c. The Box is deleted and the user try to delete a slice -> the widget should:

1. remove that slice from the state
2. create a new box component with the variants in the state
3. update the refIds on the existing variants (since the refIds are referring to non-existent instances)

Additional context
In a way it's an edge case, since the user is supposed to never delete the Box component. But it's definitely something to cover, since if it happens for any reason, and it's not possible to undo, all the work done is lost (the only way it's to reset the widget state and re-create all the variants by hand)