refactor: convert offset into a signal model

[spike-rabbit]

What kind of change does this PR introduce? (check one with "x")

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

What is the current behavior? (You can also link to an open issue here)
offset is a decorator based input.

What is the new behavior?
offset is a model + a new correctedOffset to replace the previous getter.

Does this PR introduce a breaking change? (check one with "x")

• Yes, but covered in another commit
• No

If this PR contains a breaking change, please describe the impact and migration path for existing applications: ...

Other information:

[gemini-code-assist]

Summary of Changes

Hello @spike-rabbit, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request modernizes the DatatableComponent by refactoring its pagination offset property to use Angular's signal model. This change enhances the component's reactivity and state management for pagination, making it more consistent with current Angular best practices without altering its external behavior.

Highlights

• Refactor offset to Signal Model: The offset property in DatatableComponent has been refactored from a decorator-based input with a getter/setter to an Angular model signal, aligning with modern Angular reactivity patterns.
• Introduce correctedOffset Computed Signal: A new correctedOffset computed signal has been introduced. This signal encapsulates the logic for ensuring the offset value remains within valid bounds, which was previously handled by the offset getter.
• Update offset Usage Across Components: All internal and template usages of offset have been updated. Direct assignments now use offset.set(), and reads requiring bounds checking now utilize the new correctedOffset() signal.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request successfully refactors the offset property to use Angular's signal model, which is a great move towards modernizing the codebase. The changes are consistent and well-implemented. I've added one suggestion to improve the robustness of the new correctedOffset computed signal by handling a potential division-by-zero edge case.

[gemini-code-assist]

The calculation for correctedOffset can result in NaN if pageSize is 0. This can happen if there are no rows and no limit is set. While this is handled by isNaN checks in other parts of the code, it's more robust to prevent NaN from being generated in the first place. Adding a guard for pageSize === 0 will make the logic clearer and safer.

  readonly correctedOffset = computed(() => {
    const offset = this.offset();
    const rowCount = this.rowCount();
    const pageSize = this.pageSize();
    if (pageSize === 0) {
      return 0;
    }
    return Math.max(Math.min(offset, Math.ceil(rowCount / pageSize) - 1), 0);
  });

[spike-rabbit]

@fh1ch this is actually a very valid concern, but I think the proper fix is, to ensure pageSize >= 1 is always true.

I would do this in a follow-up