Reactivity lost if awaited function precedes?
So this is reactive (reloads the desired componant), but is out of order from what I need to happen.
This does not reload the desired component, but is the correct order for what I need to happen. How do I resolve this situation?
I need to ensure that the backend is updated first because the component that is loaded fetches the updated data as a createResource, so I need to make sure that data is correct. I am trying to avoid attempting to keep state in sync between the backend and frontend by using the backend as the source of truth. Since this is a Tauri app, since the backend is local, delays are not an issue.
19 Replies
what does
set_session
and props.setActiveSession
do?
(also can you syntax highlight with ```tsx ?)set_session is a tauri function calling the backend:
props.setActiveSession is the setter for a signal in the parent component
pretty sure you can think of the set_session as a fetch. The difference is that it's fetching from a local instance of the Tauri backend: string goes out, string comes back.
in case it matters this is in the parent component:
The idea is to use the activeSession as a trigger to validate that the session in the backend which then triggers a validation of whether the scope is set in the backend. These are used to conditionally render the parent component. It sounds convoluted and it kinda is, but it's because I am trying to rely on state on the backend, not the frontend.
mm strange, from the looks of it, it should be fine. I know sometimes
await
can do funky stuff in solid, for example using it inside an effect can cause bugs (any signal called after await won't cause the effect to re-run), but I don't think that's what's happening here.not sure how that works for the highlighting. I 've chosen not to use typescript because I can't deal with all the error messages. I kinda want to limit the number of things I'm trying to learn at one time. Solid and Rust are enough with all the other libraries associated.
or jsx
const because_like_this = 'it looks better';
return <div/>
```
at least on desktop
gotcha, so you just add the tsx or jsx after the ```?
exactly
ok, not done that before. Cool!
just for sanity check: can you do
Odd! That seems to be working. I'll do some more testing to make sure, but weird. I'm very curious why that would change anything functionally.
what does
this log?
It logs the correct Id, but it fails to be reactive - i.e. the parent component is not rendered.
I did however have to remove the {} from:
Because I was getting the error that a signature could only be used in tsx, or something like that
a ye lol typo
should have been
await set_session({id:sessionSelected()});
or whatever u had before
i guess there was a typo here too:
current that doesn't work:
this does seem to work:
the only difference seems to be that the call to the signal getter is happening inside the await in my initial code. It's also called repeatedly, but that doesn't seem likely to be an issue.
If the problem is that the signal getter is called inside the await, that might warrant a deeper dive into the reason or maybe an informative post indicating that this shouldn't be done (calling the getter inside an await)
Calling the getter after await should be fine as this is just an event handler (not an effect or memo).
What you describe suggests that the value of sessionSelected() is changing between when that click handler starts and when the async server call completes. Are you sure there isn't something else setting that signal in the meantime? The safe option is probably capturing the value at the start of the handler - like the second code sample above is doing. That way you know you are using the same value all the way through.
What you describe suggests that the value of sessionSelected() is changing between when that click handler starts and when the async server call completes. Are you sure there isn't something else setting that signal in the meantime? The safe option is probably capturing the value at the start of the handler - like the second code sample above is doing. That way you know you are using the same value all the way through.
they mention
It logs the correct Id, but it fails to be reactive - i.e. the parent component is not rendered.@d34dbug if possible could u make a reproduction of it in the solid playground?
I'm not sure as I won't have time til Monday at the earliest and I'll have to figure out how to simulate a basic backend behavior. I'll see what I can do.
😦 Looks like I'm not going to be able to at the moment. Turns out I got sick and it put me out of commission for several days. I'm just too way behind on where I'd like to be on my project now. Sorry.
I am sorry to hear! Hope you feel better soon!
Thank you. I am feeling much better than I was, but I am so behind.