feat(Table): Conditional actions

[lordpixel]

Hi team,

This is a PoC on how we could handle conditional actions for Table.

This would add to Table:

• an opt-in prop resolveRecordActions. A function that receives 1) the current record and 2) the list of actions defined for the table; and returns the set of actions for that specific record.
• the minimal changes to make this work without making breaking changes

How to test

1. yarn cosmos
2. visit Conditional actions fixture

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/espressive/cascara/J8tefv3usYuK76HZ41SmxZ5cqxsZ
✅ Preview: https://cascara-git-feature-fds-142-espressive1.vercel.app

[brianespinosa]

I think I do like the concept of this function... I think however that we still will need to make the breaking change of moving actions to its own prop, and have this function be part of that object map. Semantically, we have actions inside a different object on dataConfig and then a prop at the root of the component. From a DX perspective, this feels hidden. If we move these parameters to the same location, we are grouping their relationship at the API level. I think we could still use this... but just relocate it.

What probably makes the most sense is creating the new actions prop and then placing this at the root of that object. Then also letting people define actions in that prop. We and add a warning for anyone still defining actions inside of dataConfig so they know to move to the new API. That will also help us clean up any refactoring in the codebase before deprecating that style of dataConfig and removing the code.

We can go over each of these in our meeting on Tuesday when you are back. Thank you for putting this together. It looks like this gets us part of the way there. 💪🏽

[brianespinosa]

@lordpixel this looks good to me... however, this is not a breaking change yet, right? Tables will still work with the old API. The only difference is that we added the new API and a deprecation notice for the old API so devs know it is going away. We only want to define something as a breaking change once existing implementation goes away... and we hopefully only have to do that after giving a few releases for developers to get their implementations migrated, which is what we are doing here. <3

[brianespinosa]

Please change the tagging of this PR to feat since we are not breaking anything yet. The old API should still work for a couple releases with a warning message.

[lordpixel]

@lordpixel this looks good to me... however, this is not a breaking change yet, right? Tables will still work with the old API. The only difference is that we added the new API and a deprecation notice for the old API so devs know it is going away. We only want to define something as a breaking change once existing implementation goes away... and we hopefully only have to do that after giving a few releases for developers to get their implementations migrated, which is what we are doing here. <3

You are right @brianespinosa, this is not a breaking change as we are still supporting the old way of defining actions. It somehow got stuck in my mind. Fixed, thanks!