Skip to main content
Question

(Critical Impact) Conflict between annotations and SLOT + properties

  • March 20, 2026
  • 0 replies
  • 22 views

Olivier_ONDO

DO NOT use “Slots” after annotations are implemented !

Problem Reproduction: (The actual use case is to design a "Grid Cell" type component to configure a table as desired. Component A: the editable content, Component B: the table cell, Component C: a variant component to manage the cell's normal and focus states.)

1- First, create an autolayout component (A) with text. Add a “text property” to the text.

2- Nest instance (A) within an autolayout component (B). Add a “swap instance property” to component (A) so that it can be swapped by any other component.

3- Nest instance (B) within an autolayout component (C). An instance (C) should then be able to display the added editable properties (text and swap instance).

To reproduce the problem and make it simple, there's no need to transform component (C) into a variant to fit my use case example.

4- Next, let's assume we previously documented our component (C): add two "measurement" annotations to identify two random padding elements (not on intances).

5- Then, in component (B), wrap instance (A) with a slot. (This will allow adding as much content as desired to a single cell, rather than just one.)

6- Now, consider that you want to update your documentation a few months later by removing the annotations because you want to change them. Remove the annotations from component (C).

Observations after removing the annotations:

- The delete snackbar shows 3 or 4 annotations removed, while 2 had been added.

- Instance (C) is altered because the editable properties (text and instance swap) no longer appear. There is also a visual alteration because if instance (C) was configured in any way, it is reset to zero.

 

If you redo the same without adding a Slot, things work … (the cause ?)

 

Critical impact:
A library implementing “Slot” even with limited documentation, especially one using "measurement" annotations, can, in this context, significantly break components and their dependencies, requiring considerable rework.

This makes me hesitant to use annotations on components, preferring instead to use them on instances (which is unfortunate as it will significantly increase the documentation size).

 

Further investigation:
Are the basic annotations affected by this issue? Are properties other than "text" and "swap instance" also impacted?  

 

Temporary solution: Delete all annotations on the components before you update them with “Slots”. But this needs to be known beforehand.

 

One thing is certain: I don't have time to waste fixing my library and its documentation for this because I’m implementing the long-awaited “Slot”.