sketch-hq/sketch-assistants

Detect detached symbols

Closed this issue · 10 comments

jedrichards commented

There has been a lot of user research and feedback from designers saying that detecting the presence of "detached symbols" will be a super useful rule to have.

So this means detecting when a user has clicked "Detach from symbol" on a symbol instance, and converted it to a plain group, breaking the link with the symbol master. This can be a major problem in large organisations that require strict adherence to design systems using libraries and symbols.

This issue is to discuss how to implement a rule that achieves this. This is tricky because, as far as I know, once a symbol has been detached and converted into a group there is no record in the file JSON that the group was ever previously a symbol instance.

One idea has been to update Sketch to record a note in the group's userInfo property that it was previously a symbol instance ...

Or is there another way?

craig006 commented

@jedrichards I like that idea, and it's about the only way I can think to do this.

The part that I'm not so sure about is how does a designer correct this, let's say in the case that they legitimately detached. How do we allow them to remove the "reference" and allow the group to not be considered a detached symbol anymore?

craig006 commented

Perhaps this is good example of “autofix” from an assistant, when clicking fix the user has two options:

  1. Replace the group with an instance of the symbol
  2. Remove the reference to the original symbol master

This can come in the future as a way to rectify the problem

jedrichards commented

Yep I think that works. Initially the remedy will be to either ignore the violation, or remove the group and replace it with a fresh one. I get the sense the important thing will be catching these sorts of costly mistakes in documents, even if the fix is a bit clunky. In future we could have a dedicated autofix ...

HugoDaniel commented

👍

Ive been looking into the detached symbols and trying to level up my knowledge of them in file JSON. I also couldn't find a way to revert a given group back into its symbol instance. Could not find any layer info that persists after the detachment takes place, and no way to access the previous undoable actions in the file (which could eventually be a way - accessing the actions log/undo info).

jedrichards commented

Yeah we would need to make a change to Sketch so that it begins to record info about detached symbols in the JSON.

As for a future "autofix" I'd imagine the implementation of the autofix (i.e. how to convert the group back to a symbol instance) would be a Sketch concern, all the rule would do is signal the intent ... I'm currently thinking of it a bit like dispatching a Redux action or something ...

e.g.

utils.report({
  node: group,
  message: 'Unexpected detached symbol',
  fix: {
    type: 'CONVERT_GROUP_TO_SYMBOL',
    group: group.do_objectID,
    symbol: group.userInfo.detachedSymbolId
  }
})
  • 👍1
craig006 commented

The change to support this from the sketch app has been merged. Any Symbol or Style that is detached will leave a userInfo entry on the layer.

The userinfo entry will be keyed by 'com.sketch.detach' and will contain information about what was detached.

  • 👍1
  • 🚀2
jnozzi commented

Heads up: sketch-hq/Sketch#29516 has been submitted for CR. :-)

  • 🎉1
sonburn commented

Is it worth differentiating between how the symbol instance was detached? If the instance was detached because the symbol was deleted, or something along those lines, then I think this will be really helpful. But if the instance was detached by the user manually, in order to make a modification that the symbol didn't allow for, then will it be more of a nuisance to get alerts about it?

jedrichards commented

@sonburn Including a reason why the symbol was detached (e.g. symbol deleted vs. user clicked detach etc) is a neat idea, and could perhaps be useful for various use cases.

But as for whether certain sorts of Assistant results could be a nuisance, the hope is that teams will be able to fine tune their experience to suit their internal workflows and processes. Adding an Assistant to a document is optional, and even once added you'll be able to silence or mute certain sorts of results if they just get in the way. Or the ultimate escape hatch is to write your own Assistants that work the way you need them to - you can write these from scratch, or extend from other Assistants to piggy-back on their functionality.