#any way to wrap a setter?

36 messages · Page 1 of 1 (latest)

whole pumice
#

setter is of type Setter<RemoteData<T>>

#

so shouldn't successSet be the same?

#

sorry I meant the same type

#

changing const successSet: Setter<T> to const successSet: Setter<RemoteData<T>>

#

I see what you mean

# 
type CustomSetter<T> = (val: T) => void
#

Setter is just a function definition

#

I didn't check, I might not be completely understanding the issue tho

#

oh

#

What error do you get

#

I don't think you'd be able to extend Setter 🤔 Maybe a custom function to do the same thing

#

I honestly couldn't tell you, I just tried it out and am also confused

#

Sorry

old summit
#

you have to return the same thing passed to the setter

#

it's more complicated than just that so i don't expect just adding return val would work

whole pumice
#

yeah just tried

#

wait

#

it does work

#

only if you also handle the check for a function

#

I thought I tried this

old summit
#

oh it does just work

#

interesting

whole pumice
#

I swear I tried this 10 times 😂

#

The types were doing some magic that didn't make sense to me

#

at least the intersections

whole pumice
old summit
#

that compiles because it satisfies the type, even if it doesn't set anything

#

the point is that all setters need to return the new value that the signal is being set to

#

currently yours does not

#

same, until it actually isn't safe

#

probably

#

is there any reason why you're not using a resource instead?

#

you're probably best off asking someone else tbh, i'm not sure

crimson portal
#

Nice interesting to look at the approach and what youre trying to do.
I think there's too many constraints the way you've set it out, that may not be necessary.
Essentially you just want to expose some functions to facilitate managing state? And technically all you can do is map signals and setters, any abstraction will just be by design.

So if you want the returned setters to be of type Setter<T> you need ways to map to and from T to each member in the RemoteData<T> union. The setters act as a way to map to it, but if you want to be able to use set(x=>!x) as callback you also need a way to get current value from the signal of type RemoteData<T>

But only makes sense for DataSuccess as its the only one with data.
And if you need to set error you would want probably to pass error code but that wont be in type T either.

I put some code on your example that hopefully can make clear what Im saying https://playground.solidjs.com/anonymous/17075523-435b-41e7-9ad1-ab9e1f0ed496

Solid Playground

Quickly discover what the solid compiler will generate from your JSX template