Add visual cues to foreign key columns

[seancolsen]

Current behavior

• When viewing a table, the user has no indication which columns have foreign key constraints.

Desired behavior

• Column header displays referenced table and referenced column.
• Column header menu displays referenced table.
• Cell values are stylized differently.

Notes

• If two columns are both part of the same multi-column FK, then they should both receive the foreign key styling.

Specs

• Foreign Key Constraints Spec -- see Scenario 3a.

See also

• Add visual cues to help users distinguish multi-column foreign key constraints from single-column ones #952

[seancolsen]

@ghislaineguerin one small concern -- the cell styling of a background and border radius on the text looks great with simple numbers -- and I imagine styling will suffice in the vast majority of cases. But I wonder if it's worth considering the scenario where the FK value is a text that wraps within the cell. In that case the border radius won't look so good. Would it be better to apply the background color to the entire cell instead of just the text? Or perhaps the text-wrapping scenario will be rare enough to disregard?

[ghislaineguerin]

@seancolsen I worry about how that might communicate that the records are 'linked,' meaning they exist elsewhere. My idea with separating them visually from the table was that. If we merge them into the cell, we are losing that. I'll test it out and see if we can work something out or test with wrapping to see how that looks.

[pavish]

FK value is a text that wraps within the cell

@seancolsen @ghislaineguerin
For cases where the FK value is a lengthy text, I'd suggest that we rather add ellipsis to the end instead of wrapping it.

1. The cell height has to be explicitly mentioned and not controlled by the browser, to support virtual scrolling.
2. Spreadsheets do not wrap text usually.
3. The cell styling from the UX would work for all cases when we do not wrap text.

[kgodey]

@pavish Won't we need to support different cell heights for the record preview feature? Also, how would editing the value work if the user can't see the whole value?

[pavish]

@kgodey

Won't we need to support different cell heights for the record preview feature?

• Yes, we will be supporting this. This is possible because the cell heights for the preview feature can be calculated prior to rendering, considering that each key value pair takes a single line for itself within the cell. However, if the text is wrapped and can take any arbitrary number of lines per key value pair, we cannot estimate the space it would possibly take without rendering it first, which we cannot support and would not require.
• We can provide options for users to still manually resize both the column and the row (similar to spreadsheets).

how would editing the value work if the user can't see the whole value

• On edit mode, the user can see the entire value. This is the current behaviour as well, lengthier text is truncated on normal mode but on edit mode, it transforms into a textbox with the full value. For longer texts, we'll be using a textarea moving forward.

The interface I have in mind would work similar to airtable and would also satisfy our UX.

[kgodey]

Okay, thanks, @pavish, sounds good to me.

[seancolsen]

I'm closing this ticket per a discucsion where we decided to pursue a simpler design.