Adding (1) to duplicated elements – RC4

I’m really in the weeds here, but I just noticed that when you duplicate an element it adds (1) to each duplicated element.

So, in this example I first duplicated “Button” then I duplicated “Button (1)”…

image

This feels like a bug to me – unless I’m missing a use case?

I think it used to be “Copy of Button” and we switched it to (1) and if you duplicate multiple times (the same original element) it will increment. It’s appending more (1) because you’ve duplicated the duplicate. Going to leave this for now but open to ideas on a different format.

I guess the behavior is unchanged from Pro3?

It just felt like new behavior to me because it was adding (1) to elements that had the default name (which you can see in my screenshot above). However, I guess there’s a whole bunch of logic to when the (1) gets added…

  • If you duplicate an element with a default name (Button, Headline, etc), it does not add (1)
  • If you duplicate a section/row/column with the default name (e.g. Section 1), it increments the number of the duplicate accordingly (so the duplicate becomes Section 2, and it if there was already a Section 2, it becomes Section 3, etc. etc.)
  • If you duplicate an element with a custom name (“Custom Button”), it adds the string (1) to the end of the custom name each time you duplicate it (so you can end up with the (1) (1) (1) thing)
  • If you duplicate an element you added to the page by dragging a preset from the elements library – even if that preset uses the default name – it adds (1)

It’s that last one that was throwing me off, because I was working on a page where everything was imported from a preset… so it was adding (1) to literally everything I duplicated, even though they all had default names :crazy_face:

… all that to say that I’m the type of person who’d prefer it didn’t add (1) to anything. But I also can imagine that some people find it useful… so maybe one day there will be a preference… :pray:

If you duplicate a section/row/column with the default name (e.g. Section 1), it increments the number of the duplicate accordingly ( so the duplicate becomes Section 2, and it if there was already a Section 2, it becomes Section 3, etc. etc. )

Yes, this one has been a bit bothersome for a while. It’s one of those things where the history of the codebase leads to strange things. If you check the dev console you can see that the element’s _label isn’t even set so it gets one automatically. In early versions of the tool, you couldn’t rename elements and we started automatically indexing elements by appending a number to their label. We’re most likely going to remove this and set the label to “Section 1” when the element is created.

If you duplicate an element you added to the page by dragging a preset from the elements library – even if that preset uses the default name – it adds (1)

That’s very strange - shouldn’t be doing that.

In both cases, we are getting notes together for some maintenance to the Outline pane. I’ll add these considerations there and we’ll get them figured out.

:+1:

Whenever you get closer to making those changes, I’d be curious to see what other folks think about this topic of “labeling of elements”. I just wonder if you have to do a bunch of complex stuff, and maybe there’s a world in which elements could either have a default or explicit label… and nothing changes unless a user explicitly makes a change to the label.

Like maybe the UI just shows the default name in a clearly default state (like a slightly lighter font-weight / color when it’s just “Section” or “Button”), and then if someone explicitly sets it to something else, that label is passed on to any duplicate until explicitly changed.

Anyway, I know there are all sorts of considerations you folks have to take into account, so a conversation for another day…

1 Like

Yeah, definitely worth thinking on. If you drag in “Posts (List)” for example, you’ll notice elements labeled “Figure” and “Article” but they are just Divs that have been renamed to hint at the structure. That’s how the whole Dynamic section of elements works. It’s just core elements preconfigured and renamed. I could see how over time that could become ambiguous. I do like that we can rename things to explicitly describe intent and behavior, but perhaps there should be some reinforcement of the core element underneath so you know what to expect from the available controls and functionality when you inspect it.

2 Likes