Unintended merge of field with Component per item

Created on 21 May 2025, 13 days ago

Problem/Motivation

Using Component per item with a multi-valued entity reference field (taxonomie) merge and duplicate data in every iteration of the component

Steps to reproduce

Install Ui pattern Version : 2.0.3
install UI Suite DSFR 1.1.0-beta6
Have a content type with a multi valued entity reference (taxonomy term) field
Configure the display of the field to be component per item, choose component and use data from a field to select the field in the desired slot

See screenshots attached

🐛 Bug report
Status

Active

Version

2.0

Component

Code

Created by

🇫🇷France hproustacx

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @hproustacx
  • 🇫🇷France pdureau Paris

    Hi Hugo,

    Some of UI Patterns sources plugins are not really data sources but context switchers:

    It seems you are:

    1. Editing a "Component per item" formatter on a reference field (so, you start from the field context)
    2. Picking the same field in "Data from a field" (so you stay at the same field context, but you lost the "per item").
    3. And then you pick a field formatter

    Don't you have a the choice to pick the same formatter directly at step2?

    It looks like (without being identical) the yesterday situation when you were:

    1. Editing a "Component per item" formatter on a reference field (so, you start from the field context)
    2. Picking a "Referenced entities" source (so you move "up" to the content entity context)
    3. And then picking the same field "Data from a field"

    Maybe our UX is confusing. So I am proposing to:

    1. Add a label with the current context at the beginning of the component form

    Only the most precise available context, as provided by to the configurable plugin:

    • Component field formatter: [Field]
    • Component per item field formatter: [Field item]
    • Layout: [Entity] or nothing (or [Page] or [Content] when they will be added to UI Patterns 2]
    • Block: [Entity] or nothing (or [Page] or [Content] when they will be added to UI Patterns 2]

    I skip Views plugins because there is no context switching (yet) here.

    1. Prefix the context sensitive source with the expected context

    2. Rename our context switchers to make the switch more explicit

    With an Unicode arrow in the label, for example:

    Wrapping up

    So, for the today example, you will have this:

    1. "Component per item" [Field item]
    2. "[Content] ➜ [Field]"
    3. The selected field formatter

    To make it obvious we went from "Field item" to "Field".

    For yesterday example:

    1. "Component per item" [Field item]
    2. [Content] ➜ Referenced [Content]
    3. [Content] ➜ [Field]

    Is it clearer with this labelling? I am open to any suggestions or wanring ;)

  • 🇫🇷France pdureau Paris

    Checked with Hugo. No bugs found. It is only an UX issue, so let's go.

  • 🇫🇷France hproustacx

    After discussing with Pierre, indeed not a bug, but rather an UX / Label issue that might lead to confusion.

    Proposed resolution

    Introduce categories/group in the select output when selecting data from a field to further explain the context.

    To take it further
    When already in a field context, remove the same field from the select options of Data from a field to avoid context loop/duplicate or display warning upon selection.

  • 🇫🇷France pdureau Paris

    Before:

    After:

    It make the context tracking easier from a source to another:

    a

  • 🇫🇷France pdureau Paris

    First proposal done. Now, let's collect feedbacks.

  • Pipeline finished with Success
    12 days ago
    Total: 612s
    #503895
  • 🇫🇷France pdureau Paris

    Also, why all the Context Switchers are in the "Converted" group? why not in the main group or a specific "Context switching" group?

  • 🇫🇷France pdureau Paris

    Also, why all the Context Switchers are in the "Converted" group? why not in the main group or a specific "Context switching" group?

    Mikael proposes to remove the "Converted" group because it seems users don't care about this.

    And introduce a group by Context, so

    • Component
    • Block
    • Wysiwyg
    • Entity
      • [Entity] Link
      • [Entity] -> Field
    • Field
      • [Field] Formatter
      • [Field] Label
  • 🇫🇷France pdureau Paris

    Finally, I am proposing to gather context switchers together;

    • Component
    • Block
    • [Entity] Link
    • [Field] Formatter
    • [Field] Label
    • Wysiwyg
      • [Entity] -> Field
Production build 0.71.5 2024