Using string as the selection type is a common pattern among component libraries such as Ariakit (we use it as base), and Radix. Also, native select has a string value. I have a question to understand the use case better: Why can't you use a string state to pass to your filter? (like on the first example)

Also, you know you don't have to create a use-callback for this right? This code will work, for example:

import React from 'react';
import { Filter, FilterItem, Stack, Text } from '@vtex/shoreline';

export default function App() {
  const [state, setState] = React.useState({ value: 'blackberry' });

  return (
    <Stack>
      <Text variant="body">Value: {state.value}</Text>
      <Filter
        label="Fruits"
        value={state.value}
        setValue={(value) => setState((prevState) => ({ ...prevState, value }))}
      >
        <FilterItem value="apple">Apple</FilterItem>
        <FilterItem value="banana">Banana</FilterItem>
        <FilterItem value="blackberry">Blackberry</FilterItem>
        <FilterItem value="cramberry">Cramberry</FilterItem>
      </Filter>
    </Stack>
  );
}

Playground: https://stackblitz.com/edit/stackblitz-starters-wx4zg1?file=src%2FApp.js.

Why can't you use a string state to pass to your filter? (like on the first example)

The examples B, C and D are just a simplified version that would represent my problem. I don't think it's useful to have an object state instead of a plain string - it was just a simple way I found to convey the problem. In my scenario, I actually have an array of strings (it's a multiple Filter) and each value must be mapped to something else (e.g. Number.parseInt()) - I didn't give more details because it's out of the scope of the suggestion.

The main point I wish to convey is that we don't always have a Dispatch<SetStateAction<S>>-typed callback ready for use, and there's a way to simplify the prop type and make it more generic simultaneously

you know you don't have to create a use-callback for this right?

Yes, sometimes I do this to prevent a ref-changing anom function to trigger a random internal useEffect. It's not the case with the Filter component, I guess I wanted to cover any loose tips in the examples but just made them unnecessarily complex, sorry 😅 hahahaha

Oh, I think I got this time. So, its just a type issue, right? Changing the type to also accept ((prevState: string | string[]) => void) would work for you?

Yes, surely!

Changing the type to also accept ((prevState: string | string[]) => void)

@matheusps just to align: we have defined what should be done, right?