Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Reconsider the interface of dropdown menus #634

Open
AlexVelezLl opened this issue May 8, 2024 · 1 comment
Open

Proposal: Reconsider the interface of dropdown menus #634

AlexVelezLl opened this issue May 8, 2024 · 1 comment
Labels
Component: KDropdownMenu P3 - low Priority: Stretch goal TAG: dev experience TODO: needs decisions Further discussion and planning necessary TODO: Needs investigation type: proposal New feature or request

Comments

@AlexVelezLl
Copy link
Member

Product

Kolibri, Studio.

Description

In #583 we discussed how KDS should expose dropdown menus and context menus. We currently have a KDropdownMenu component that can behave like a contextMenu if we pass it an isContextMenu prop (see the description of #583). However, this can be very tightly coupled if we want to extend dropdown functionality later to render more than just menus.

There are proposals to improve this, such as using composables const { isOpen, open, close, positionX, positionY } = useKDropdown(); to decouple the functionality, this could bring several benefits (see this comment), but research is needed to determine if it is technically feasible.

Another proposal suggests maintaining the Components interface and creating separate components: KDropdown, KMenu, KContextClick, while keeping KDropdownMenu as a reusable component for the most common use case. This approach would provide us with a more flexible interface while maintaining its simplicity, allowing us to use the base components in other contexts if needed.

We still need to investigate further into the possibilities of improving the dropdown menu implementation and determine what steps we can take in KDS.

@AlexVelezLl AlexVelezLl changed the title Proposal: Reconsider the architecture of dropdown menus Proposal: Reconsider the interface of dropdown menus May 8, 2024
@MisRob MisRob added the type: proposal New feature or request label May 8, 2024
@MisRob
Copy link
Member

MisRob commented May 20, 2024

For the current interface see "Context menu" section in the KDropdownMenu and isContextMenu prop. The main advantages for this API are

  • Ease of use
  • Compatibility with the existing KDropdownMenu
  • Compatibility with existing libraries
  • Doesn’t require larger refactoring

and disadvantages are

  • Inflexibility due to the tight coupling to its parent element
  • Scalability
  • Dropdown menu has different requirements and usages than context menu

One of the promising improvements resolving the disadvantages could be an API similar to (originally suggested by @bjester):

<template>
  <div>
    <KIconButton
        @click="open" 
    />
    <KMenu
        v-if="isOpen"
        :options="menuOptions" 
        :positionX="positionX" 
        :positionY="positionY" 
    />
  </div>
</template>
<script>
    import useKDropdown from './useKDropdown';
  
    export default {
        setup() {
            const { isOpen, open, close, positionX, positionY } = useKDropdown();
            const menuOptions = computed(() => [
                { text: 'Item 1', onClick: close },
                { text: 'Item 2', onClick: close },
                { text: 'Item 3', onClick: close },
            ]);
            return { isOpen, open, close, positionX, positionY, menuOptions };
        }
    }
</script>

For moving on, we need to

  • Clarify the intended internal and public relationship of menu components (KDropdownMenu, KMenu, KContextMenu,..)
  • Polish the suggested API to be simpler for use in the most common use cases, while still providing ways to override it
  • Clarify compatibility with the popover library or scope refactoring needed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: KDropdownMenu P3 - low Priority: Stretch goal TAG: dev experience TODO: needs decisions Further discussion and planning necessary TODO: Needs investigation type: proposal New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants