feat(pagination): add pagination

[marcjulian]

PR Checklist

Please check if your PR fulfills the following requirements:

• [ ] The commit message follows our guidelines: https://github.com/goetzrobin/spartan/blob/main/CONTRIBUTING.md#-commit-message-guidelines
• [ ] Tests for the changes have been added (for bug fixes / features)
• [ ] Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• [ ] Bugfix
• [X] Feature
• [ ] Code style update (formatting, local variables)
• [ ] Refactoring (no functional changes, no api changes)
• [ ] Build related changes
• [ ] CI related changes
• [ ] Documentation content changes
• [ ] Other... Please describe:

Which package are you modifying?

• [ ] accordion
• [ ] alert
• [ ] alert-dialog
• [ ] aspect-ratio
• [ ] avatar
• [ ] badge
• [ ] button
• [ ] calendar
• [ ] card
• [ ] checkbox
• [ ] collapsible
• [ ] combobox
• [ ] command
• [ ] context-menu
• [ ] data-table
• [ ] date-picker
• [ ] dialog
• [ ] dropdown-menu
• [ ] hover-card
• [ ] input
• [ ] label
• [ ] menubar
• [ ] navigation-menu
• [X] pagination
• [ ] popover
• [ ] progress
• [ ] radio-group
• [ ] scroll-area
• [ ] select
• [ ] separator
• [ ] sheet
• [ ] skeleton
• [ ] slider
• [ ] switch
• [ ] table
• [ ] tabs
• [ ] textarea
• [ ] toast
• [ ] toggle
• [ ] tooltip
• [ ] typography

What is the current behavior?

Closes #119

What is the new behavior?

Does this PR introduce a breaking change?

• [ ] Yes
• [X] No

Other information

[marcjulian]

I would like your feedback @goetzrobin on how we should implement previous/next. I added it as component but now I would need to handle passing href or routerLink.

Open tasks

• [x] update storybook
• [x] copy pagination to cli

[goetzrobin]

I would like your feedback @goetzrobin on how we should implement previous/next. I added it as component but now I would need to handle passing href or routerLink.

Open tasks

• [ ]  update storybook
• [ ] copy pagination to cli

Interesting question.... My mind went to thinking that you can just go with providing both as inputs (href & routerLink) and under the hood determine to use routerLink or href. Although if we pick one for now I'd go with routerLink as this is pretty much the default of how we link in Angular apps.

[marcjulian]

Okay i added href as input to Next and Previous component, using routerLink for navigation. I guess routerLink is the better approach anyways, the pagination probably never points to an external page.

[goetzrobin]

@marcjulian looking at your example now I think we should change it to router link and also add support for the additional router link option inputs. Your argument that this will most likely always be internal navigation makes sense! Sorry about the change of mind here!

[marcjulian]

If I rename the input to routerLink it will act as input and as directive in the preview.

The routerLink directive will be applied to hlm-pagination-previous and passed as input to the component and then applied to the anchor tag.

I see following options:

1. Move a tag out from hlm-pagination-previous/next and wrap the component in template with a tag
2. Rename to routerlink to avoid applying the directive too

With approach 1. the user has full access to the anchor tag in the template, with 2. we would need to handle the additional router link options.

[goetzrobin]

If I rename the input to routerLink it will act as input and as directive in the preview.

The routerLink directive will be applied to hlm-pagination-previous and passed as input to the component and then applied to the anchor tag.

I see following options:

1. Move a tag out from hlm-pagination-previous/next and wrap the component in template with a tag
2. Rename to routerlink to avoid applying the directive too

With approach 1. the user has full access to the anchor tag in the template, with 2. we would need to handle the additional router link options.

@marcjulian Very good points. Maybe we stay with href or just do [link]="#" [linkOptions]="{ROUTER_OPTIONS_HERE}" ? I am open to hear your suggestion! We would also make routerlink a host directive for hlmPaginationLink and keep the same [link]="#" [linkOptions]="{ROUTER_OPTIONS_HERE}" inputs that are forwarded to routerlink? That way the API stays consitent?

[marcjulian]

@goetzrobin the idea with RouterLink as host directive for HlmPaginationLinkDirective is a really good idea! Haven't used it yet, really powerful!

I would prefer going with link as input for routerLink, as it is closer than href.

Which router link options do you mean should be exposed with linkOptions as input? Should we add all RouterLink inputs to the host directive and keeping the name?

For example

@Directive({
    selector: '[hlmPaginationLink]',
    standalone: true,
    hostDirectives: [
        {
            directive: RouterLink,
            inputs: ['routerLink: link', 'queryParams',  'fragment' ...], // 👈
        },
    ],
    host: {
        '[class]': '_computedClass()',
        '[attr.aria-current]': 'isActive() ? "page" : null',
    },
})
export class HlmPaginationLinkDirective {

[goetzrobin]

@marcjulian I'd say we keep all of them! Let's do link! I like it!!

[marcjulian]

I run prepare-cli to copy hlm to cli. HlmPaginationLinkDirective uses buttonVariants, relying on the button component. Do I need to add this relationship somewhere to the CLI or how is it handled?

[goetzrobin]

You probably need to adjust this part of the CLI: https://github.com/goetzrobin/spartan/blob/main/libs/cli/src/generators/base/lib/build-dependency-array.ts Similar to DEPENDENT_ON_DIALOG

[marcjulian]

@goetzrobin I think I have found it. Please try it out and let me know what to do next.