feat(app-collection): systematically add linked name and "Go to details" cells #1679
Conversation
✅ Deploy Preview for kuma-gui ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
There was a problem hiding this comment.
I took a quick look at this
Overall, I think we should wait until we have feedback from design to do this. From what I understand I don't believe this is stopping us from adding summary views across the application but only making it so you can get to them via a single click i.e. this could be seen as an improvement to the feature (once the feature is in)
Additionally I'm not even sure if we should do the shift-click thing from what I can see that overwrites the default behaviour of my browser which uses shift-click to open the link in a new window.
Honestly, it kinda feels like adding an additional link after the existing 'name' link would probably be fine here. This is what you would do if you were doing this normally. You would just add a new link into the slot.
Adding all this extra stuff to AppCollection is overloading the component with things about trays, detail views etc etc.
AppCollection is supposed to be as simple as a table as we can get.
I wanted to leave some comment here asap seeing as you asked me to, but I still think we should:
- Wait a little more for design
- Not be too hasty using the shift-click thing, I might have misunderstood in our GUI sync but I think we felt that this would be a little "power user like" anyway.
Happy to catch up on this one first thing tomorrow, but please keep working on getting the summary views in in the meantime this PR shouldn't block any of that I don't think (let me know if I'm wrong)
|
I’ll wait with this PR a little bit mainly so I know which direction #1675 will go in. I’ll likely pull the Shift-Click mechanism out of this. I still would like to add this, but it’s less relevant with the addition of the "Go to details" link. I plan to integrate a couple of things into AppCollection because they benefit from being abstracted away and into it. This avoids duplicating all sorts of things (the actions dropdown, the "Go to details" link we’re adding, etc.). That’s exactly what AppCollection should be for.
This is very repetitive and not systematic. We really want this to be systematic so we have less chance of messing it up.
Doesn’t mean it shouldn’t help us where it’s the best tool for the job. |
kleinfreund
changed the title
|
I haven't taken a look at this since we've removed the shift-click thing but wanted to say:
The biggest problem we had with our old DataOverview component was, over time people had just added more and more things to it in order to avoid being repetitive and trying to be systematic. The biggest problem with KTable is that over time people had just added more and more things to it in the same way. Where we've ended up with both of those components is extremely overloaded, difficult to manage components that in some cases tried to abstract the entire application into one component (bit of an exaggeration but you know what I mean). I want to take care to try to avoid returning to that. Now, these things maybe seem simple, but they are sometimes hard to get right, and its is often a fine balance, but sometimes its just easier and more obvious, and in the longer term more flexible, to just use a As I said its a fine balance, and sometimes hard to get right, but we should try, and with that being said I'll take a look at this again, but as it stood previously my overarching thought was, "why aren't we just using a link?" |
Yeah but the abstraction of some (!) of thisstuff was actually a good part of DataOverview that we dropped with AppCollection. We currently repeat the exact same dropdown code over about 10 list views. That’s just not great. The same applies to various additions like the "Go to details" cell or the linked name cell. We shouldn’t need to re-implement those every time. |
…ls" cells Systematically adds a “name” cell to AppCollections. The name cell will always be linked as long as either a summary or detail route is provided. Systematically adds a “Go to details” link to AppCollections that have a summary route. This is intended as the primary quick interaction to go from list to detail view when a summary view exists for that list view. This becomes relevant because the default row click interaction for list views with a summary view is to open the summary view (and no longer the detail view). Signed-off-by: Philipp Rudloff <[email protected]>
|
Draft until we figured the UX a little more. |
|
Closing this for the time being. If I pick this up again, it’ll likely happen via #1680. |
Changes
Systematically adds a “name” cell to AppCollections. The name cell will always be linked as long as either a summary or detail route is provided.
Systematically adds a “Go to details” link to AppCollections that have a summary route. This is intended as the primary quick interaction to go from list to detail view when a summary view exists for that list view. This becomes relevant because the default row click interaction for list views with a summary view is to open the summary view (and no longer the detail view).
Relates to #1681.
Signed-off-by: Philipp Rudloff [email protected]
Notes & motivation
This PR provides AppCollection with access to both the detail and summary route (if applicable). This is intended to move the responsibility for some pretty important interactions from users of AppCollection into AppCollection itself:
I think these items should be handled more systematically than they currently do. It’s easy to forget adding one of these things on the user side of AppCollection.
As an additional bonus, it allow us to move the three-dot "More" dropdown menu code into AppCollection (in #1680) to avoid repeating it in the list view code.