Implement component states

@lauriii is that screenshot correct - its the same one as #3460955

Ah I see, same screenshot, different feature, ignore me

Implementation:

Although we're waiting to take care of a few e2e things in gitlab, component/unit tests are working fine and these should get at least surface level testing

#9: updated issue summary 👍 Also … 🤩

Needs tests per #10.

I've taken a stab at making a Cypress component test - I'm not sure how to get around how much fake/boilerplate code I had to wrap it all in to make it work though.

Perhaps a candidate to replace with a proper e2e test at some point.

Current status:

Due to the overlap in functionality (regarding positioning the UI elements over components in the preview), the code in the MR for this issue (!93) was used as the base for !99 which is addressing #3460952 📌 Implement add button for top level item (section) Fixed .

That means that once !99 is approved and merged, this work will also be merged in as part of that.

Or, if this MR gets approved, it can be merged first independently.

So based on #14, it sounds like it doesn't matter which lands first:

• this MAY land before 📌 Implement add button for top level item (section) Fixed , which would require that one to be rebased
• if #3460952 lands first, then this issue can be marked obsolete

That first bullet is preferable, because it makes the individual MRs/commits to 0.x simpler.

Is that right?

@Wim Leers you are correct.

The automated tests prompted me to run a manual A11y check on on the page

There is an AA contrast violation on
div:nth-child(1) > ._previewContainer_14ww3_31 > ._xbComponentToolbar_lmyju_17.rt-Box[data-state="closed"] > ._nameTag_1uhn3_1._selected_1uhn3_11

on

<div class="_nameTag_1uhn3_1 _selected_1uhn3_11">

(obviously these are hashed classnames but it is safe to assume they are part of the NameTag component introduced in this issue.

Looks good - this is in!

Automatically closed - issue fixed for 2 weeks with no activity.