feat: useSelectable add pageOnlySelection feature

[siguenzaraul]

Description

Add pageOnlySelection feature to the useSelectable hook and OneDataCollection component to control selection behavior across paginated data. This enhancement allows developers to choose between two selection modes:

• Page-only selection (default): Selection state resets when navigating between pages
• Cross-page selection: Selection state persists across all pages

This feature is particularly useful for bulk actions that should operate either on the current page only or across the entire dataset.

Screenshots (if applicable)

[Link to Figma Design](Figma URL here)

Implementation details

What have you changed?

1. Added pageOnlySelection property to:

   • DataSourceDefinition type (datasource.typings.ts)
   • UseSelectableProps type (useSelectable/typings.ts)
   • Propagated through ExampleComponent and its props

2. Enhanced useSelectable hook (useSelectable.ts):

   • Added logic to track current page/cursor using previousPageIdentifierRef
   • Implemented useEffect hook that clears selections when page changes (only when pageOnlySelection is enabled)
   • Modified itemsStatus and selectedIds computations to filter items based on current page when in page-only mode
   • Updated totalKnownItemsCount to reflect current page count in page-only mode
   • Adjusted selection logic to respect the page-only constraint

3. Added comprehensive documentation (selectable-bulk-actions.mdx):

   • Explained both selection modes with clear examples
   • Documented the differences in behavior
   • Added usage examples with code snippets

4. Created two Storybook stories (index.stories.tsx):

   • WithPageOnlySelection: Demonstrates default behavior
   • WithCrossPageSelection: Demonstrates cross-page selection with pageOnlySelection: false

5. Updated F0Select component to use the default pageOnlySelection: false for backward compatibility

[github-actions]

✅ No New Circular Dependencies

No new circular dependencies detected. Current count: 0

[github-actions]

🔍 Visual review for your branch is published 🔍

Here are the links to:

• the Visual Review Page

• the latest build on chromatic

• the full storybook

[github-actions]

📦 Alpha Package Version Published

Use pnpm i github:factorialco/f0#npm/alpha-pr-3174 to install the package

Use pnpm i github:factorialco/f0#9ba7bc0a32f66bd6c414f6d458fe25ad71c303cb to install this specific commit

[github-actions]

Coverage Report for packages/react

Status	Category	Percentage	Covered / Total
🔵	Lines	37.34%	5736 / 15358
🔵	Statements	36.78%	5859 / 15928
🔵	Functions	26.34%	1211 / 4596
🔵	Branches	27.01%	3258 / 12059

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
packages/react/src/components/F0Select/F0Select.tsx	78.23%	61.93%	72.09%	79.51%	133, 139, 154-156, 168-170, 208, 231-234, 357-358, 362, 365-366, 386, 399, 417-418, 457, 470-493, 557-572, 578
packages/react/src/experimental/OneDataCollection/__stories__/mockData.tsx	0%	0%	0%	0%	79-1681
packages/react/src/hooks/datasource/types/datasource.typings.ts	100%	100%	100%	100%
packages/react/src/hooks/datasource/useSelectable/typings.ts	100%	100%	100%	100%
packages/react/src/hooks/datasource/useSelectable/useSelectable.ts	80.89%	69.15%	87.09%	82.41%	97, 107, 122, 134, 202, 239, 302-306, 328, 341-400, 432, 447, 466, 475, 525, 533, 542-568, 618-619, 631-636, 685, 699-703

Generated in workflow #10009 for commit 41d911a by the Vitest Coverage Report Action

[neil-krichi]

thank you!! 🚀

[sergiocarracedo]

Why we need to create ux inconsistencies across app?

[siguenzaraul]

Why we need to create ux inconsistencies across app?

Depending on the nature of the data collection, the selectAll or selection can be of only the page (as for example in time tracking, where they want the selection to always be the page and not handle indeterminate cases) or of the entire collection, as in the employees table where we want to select everything and handle indeterminate cases.

This is likely a UX inconsistency, but currently all cases are handled solely from a page-level perspective. As long as this remains the case, we should have the option to use a prop to gradually modify the behavior.

Or at least that's what they told me from product, and from my point of view, makes sense

[sergiocarracedo]

This is likely a UX inconsistency, but currently all cases are handled solely from a page-level perspective. As long as this remains the case, we should have the option to use a prop to gradually modify the behavior.

In my opinion is a big inconsistency for the users, on a page the behavior is a real select all and in other a page select all, without a different UI (a different way of doing the select, a different button, etc) the users can no notice the difference causing errors and frustration

Or at least that's what they told me from product, and from my point of view, makes sense

Well if product is agree, I don't have anything to say

[siguenzaraul]

This is likely a UX inconsistency, but currently all cases are handled solely from a page-level perspective. As long as this remains the case, we should have the option to use a prop to gradually modify the behavior.

In my opinion is a big inconsistency for the users, on a page the behavior is a real select all and in other a page select all, without a different UI (a different way of doing the select, a different button, etc) the users can no notice the difference causing errors and frustration

Or at least that's what they told me from product, and from my point of view, makes sense

Well if product is agree, I don't have anything to say

Let me check with all the products, as it might only be necessary for the product that caused the complaint, and it's not a common issue. In addition, we should improve the design of this so the user clearly understands what's happening