fix(link-editor): update behaviour so that we can save on link collection items

[seaerchin]

Problem

This PR fixes an issue with ISOM-1654 (and more deeply, the link editor)

Closes ISOM-1654

Solution

1. add a LinkEditorContext that all the child components read from. we do this so that the state can be unified for what the href currently is + the currently active link item
2. pass onChange to the context and have the children reference it. this isn't quite ideal yet because page/file elements live outside of the context but we're manually passing the same onChange + callsite is limited, this shuold be ok
3. fix overflow for ref control so that overflowing links display as truncated elllipsis
4. bug-fix for tab behaviour so that doing any action on any other radio tab resets the state but changing the radio itself doesn't reset the state

Videos + Screenshots

Screen.Recording.2024-11-07.at.1.00.27.PM.mov

overflow now

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
isomer-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 12, 2024 7:16am

[linear]

ISOM-1654 Unable to add file collection item on collection

[linear]

ISOM-1654 Unable to add file collection item on collection

[datadog-opengovsg]

Datadog Report

Branch report: fix/file-collections
Commit report: 21eddab
Test service: isomer-studio

✅ 0 Failed, 180 Passed, 34 Skipped, 37.13s Total Time
➡️ Test Sessions change in coverage: 1 no change

[adriangohjw]

for tab behaviour so that doing any action on any other radio tab resets the state but changing the radio itself doesn't reset the state

will this be confusing UX? because it's not obvious to the end user why and when it resets

[seaerchin]

for tab behaviour so that doing any action on any other radio tab resets the state but changing the radio itself doesn't reset the state

will this be confusing UX? because it's not obvious to the end user why and when it resets

yeap, getting @sehyunidaaa to double check this but i thought this was intuitive because:

1. swapping tabs doesn't do anything
2. taking an action resets

[sehyunidaaa]

Just to confirm - we had to use this logic of resetting only when there's a change because it's difficult to maintain the input across different tabs right (E.g., if file has an attachment and link also has a link, we can't keep the two)

But I agree with Chin on this, I think once the user inputs something in a different tab then it's a signal that they want to link something else

[adriangohjw]

use LinkTypeMapping instead?

[seaerchin]

i actually tried this and it didn't quite work. this is because when we say Record<LinkTypes, string>, actually what we mean is a 1:1 mapping (ie, every type in LinkType must have a corresponding string) which isn't quite what we want here. what we want is "some subset of LinkTypes to string" - i considered using Partial<Record<LinkTypes, string>>, but unfortunately that means that every type is now optional. hence, i just went iwth string for now

[adriangohjw]

why do we need to cast it though?

[seaerchin]

value is inferred as string which doesn't satisfy the type

[adriangohjw]

will it be better to ensure that the value passed into and handled by onChange enforce the LinkTypes?

[seaerchin]

this value is given by an external api (useRadioGroup) and it doesn't accept generics as far as i can tell, so we couldn't enforce it :sadge:

[adriangohjw]

nit - should this be plural LinkEditorRadios instead? since it returns a few radios and will be less misleading

[seaerchin]

i actually think the Radios is more confusing sia - wdyt about RadioGroup or Header?

[adriangohjw]

true, LinkEditorRadioGroup sounds good!