Restrict splash to one story

[Georges-GNM]

What's changed?

Closes this fronts+curation ticket

As per the ticket description, we want the tool to reflect how the frontend renders so that fronts editors will have clarity over what will appear to users. In this case specifically, as the splash can only contain up to a single story, we want to make sure this is limited in the tool as well.

The approach I've taken is to update the handleInsert and handleMove functions called when a card is dragged to a collection/group, such that if we're not adding a card to a group with the name splash, nothing has changed and the pre-existing logic keeps running to insert as normal. This only concerns the new fairground containers, so it didn't feel necessary to ensure this is implemented retroactively.

If we are adding to a splash, we check how many cards there already are in the group and which position we're inserting to:

• if there's no cards in the group already, we insert as normal
• if there's a card in the group already, and we're inserting to the bottom of it, the card we're inserting is instead moved to the top of the standard stories group
• if there's a card in the group already, and we're inserting to the top of it, the new story is inserted into the splash, and the previous story is moved to the top of the standard stories group.

Some new properties to relevant components have been added to enable checking these conditions (e.g. the ids of the groups in the collection, and the name and cards currently in the relevant group).

Manual testing would involve checking these four scenarios, for both dragging from the feed of stories and moving between groups.

The jest tests have just been updated to pass, but not take into account these conditions yet - happy to try adding these variations though.

The branch is currently up on code.

Video

insert.move.mov

Checklist

General

• 🤖 Relevant tests added
• ✅ CI checks / tests run locally
• 🔍 Checked on CODE

Client

• 🚫 No obvious console errors on the client (i.e. React dev mode errors)
• 🎛️ No regressions with existing user interactions (i.e. all existing buttons, inputs etc. work)
• 📷 Screenshots / GIFs of relevant UI changes included

[github-actions]

Deploy build 8846 of cms-fronts::facia-tool to CODE

All deployment options

• Deploy build 8846 of cms-fronts::facia-tool to CODE
• Deploy parts of build 8846 to CODE by previewing it first
• What's on CODE right now?

---

From guardian/actions-riff-raff.

[abeddow91]

It looks like the functionailty is good here but I find the nesting if else statement quite difficult to read. I think early returns would help improve the readibility here. Let me know if you'd like to work together to refactor this.

[abeddow91]

The isDropFromCAPIFeed(e) ? 'feed' : 'url' gets used several times, could we refactor this out to line 266 and store in a variable?

[abeddow91]

I find the nested if else quite difficult to parse, what would you think about refactoring this code to use early returns instead? I think it might make this decision logic easier to follow.