Improve typing on ButtonStyles

[ccrvlh]

Since props has any type, Typescript complains when access the key, this should solve that.

[snrs-art]

Hello @lowercase00,

thank you for your contribution, we will review it soon and (most probably) merge it as it is mostly only linter and typing change. It just has to be verified that merging this PR won't have on other pipelines we are running in our backstage, but as @kbalus already said - we are aiming to migrate our pipelines here to github and your contribution is puts even stronger pressure on us to do that. Hear you soon and, by the way, if you would have any suggestions you've came across some/any issues while using our DS - please consider getting them documented - we already planned to focus more on issues reported by the community, because we'd like to address practical things in the first place. Thanks

[ccrvlh]

Hello @snrs-art,

Sure, we totally understand is not trivial to change your workflow. We actually decided to make PR also for a better control on our side for the small things we were finding. We had a bit of trouble running the repo & storybook, but there's still a bit more investigation on our side before sharing with you guys, I'll let you know.

--

There's one specific change that we are planning to implement on our side, and would be great to hear your thoughts on the implementation. The use case is a the navigation experience for a module with multiple submenus (think of a "Settings" module). In our case it's at the footer of the AppMenu, and it opens a submenu with 3-4 sections (each with 4-5 links to different pages). This is mostly on the same context (the settings of the application). What we found in our case was that the experience was less than ideal for the user, since the submenu automatically closes (it renders from the AppMenu, on top of the Layout component), you have to keep going back to the original item on the AppMenu, in a big screen this is less than ideal for the end user.

So we were thinking of ways to be able to have the submenu to stay opened, but by pushing the content to the side (instead of appearing on top of it). There were a few things we found and thought of:

• We could probably make the width of the left prop in the Layout the same as the width of the submenu (left is 320px, submenu is 262px), or maybe just thrown it into a prop with a default value. By having both the same size, we could make the submenu dissolve/disappear, and render the exact same UI on the left prop of the Layout. For the user, the change would be invisible (one wouldn't know the component had changed / another component is rendering the menu), but it would minimize changes to the code structure (changes the size of the drawer, and make the submenu work outside the AppMenu context - we still have a bit more digging to do, but seems doable without breaking changes). For that to work, we would also have to add a Prop to show/hide the handle, and also to select the handle position (perhaps a percentage that would define where it would stand vertically).

• The other option we though of, was to add a prop to the submenu to keep it opened. The challenge we see in this case, is that, when you're in Module A, you still want to have access to the Submenu of Module B (so the render would be on top of the Layout). If you are inside Module B, you would probably want the submenu to push the Layout/Page content to the side. So adding this functionality this way would probably increase the complexity of the component, since it would have to be aware of the page/layout state and adapt the behavior accordingly.

Would be great to hear your thoughts on it, and see what you guys think of such a feature.

--

Another thing is that at the very beginning we also tried using a more up to date Ant version (4.17, since it was our previous lib), but found that there are some compatibility aspects that would need to be solved (drawer, dropdown, select, and a few other small things), so we went back to 4.7.0 and the problems were greatly reduced. So I was wondering if you guys have been considering upgrading Ant. Totally understand this is most likely a big change for you guys having the app in production and most probably with a huge code base written, so was just curious.

Last, also just putting ourselves opened for contributions and to help you guys tackle some of your backlog. We are a really small team building an enterprise application for finance teams so the Design System fits like a glove and we love it, perfect for enterprise: modern but feature rich, awesome stuff and thank you guys so much for sharing. We would be more than happy to help and contribute somehow, so please let us know.

[snrs-art]

@lowercase00 I will get deeper into your comment as it requires some time understanding and maybe offering an alternative.

We've already experienced some issues with this old antd version (e.g. tooltip's overlayInnerClassname bug), but for now an upgrade might be too much, but if you would be willing to, then it is always possible to try to upgrade antd in just some of specific and try to instruct webpack not to share antd's but instead inline them in those specific components (in our case this would be just our ds-tooltip - but in the end we did it in another way anyway).

Thank you for a detailed use case of a potential improvement. WIll get back to you with feedback until the end of this week.