Need help setting up sync of signals backed by GraphQL, details in a thread
GitHub
GitHub - nikitavoloboev/kuskus: Fast todo app
Fast todo app. Contribute to nikitavoloboev/kuskus development by creating an account on GitHub.
45 Replies
above code is for todo app, it works great with just signals
I have a global store of signals
https://github.com/nikitavoloboev/kuskus/blob/main/src/GlobalContext/store.tsx
GitHub
kuskus/store.tsx at main · nikitavoloboev/kuskus
Fast todo app. Contribute to nikitavoloboev/kuskus development by creating an account on GitHub.
GitHub
kuskus/store.tsx at main · nikitavoloboev/kuskus
Fast todo app. Contribute to nikitavoloboev/kuskus development by creating an account on GitHub.
onMount it loads things into the main signal
todos
here is my approach and what I want to achieve
1. user loads app, one big request to get all todos etc. is done, data saved into signals
2. user does things inside app, mutates signals
3. there is listener on signals that if signal changes, it sends a mutation to grafbase
im just not sure how to do best do this, maybe
createEffect
inside the createContextProvider
for example I can do this
and it would work
basically when I mutate the signal
todos
I also send the mutation to the db
but ideally and this would be so dreamy if I can make it workI have this effect inside the
store.tsx
which holds my global signals
so when todos()
ever changes it will also persists it to db
issue with above case is that that effect would run on first mount too
amongst other issues potentially 🤔GitHub
kuskus/store.tsx at main · nikitavoloboev/kuskus
Fast todo app. Contribute to nikitavoloboev/kuskus development by creating an account on GitHub.
the code I have now for store
I can guard against first mount like this in theory
fixed the annoying type error too
ahh
it still runs the mutation when i first load the page 😦
I basically don't want to run the effect on first load
I kind of want some api that i can wrap over signal updates
so it does not trigger the effects
that would solve my issue i think
ok this might work
ok it does not
this still runs on load
this is close to what I want I think
getting errors though
lol 39 replies
I'm sure at least one of them is not by the author 🤣
So every time a todo is "marked" as a mutation it's uploaded to the db
Do I understand the code correctly?
that sounds very manual
like you imperatively have to call "sync this"
also
what if you do
only the 2 will get synced
ok
so
i fixed the grafbase side of things
the thing I want to fix
is what you mention
its kind of manual now
so this runs on loading of an app
all todos get loaded into
todos()
signalimo you should
1. split your state management into one that is synchronised with the db and one that is not
2. make a deferred effect in which you'll read all of your state and send it to the db
3. you can split it into multiple effects if that's better
my thinking was
that I then just update
todos()
as i do
and have an effect
that if todos() get updated
persist the changes to the database
like this
this setRunMutateTodo
i added
because i had issues make it work without it
so on say TodoEditwhen you press return here
that effect runs
global.setRunMutateTodo(props.todo.id)
this gets set
and the effect runs
and persists to dbdamn
I blinked and two pages of text appeared
hehe
im excited actually
if I get this to work its so sick
right now it does actually work
setRunMutateTodo
with this thoughyou seem to always be lol
how about this?
mm
that sounds complex
like in my case as it stands now
only
todos
is actually persisted
subtasks
soon toothen make only
todos
get synced like this
I just liked the separation
synced from not syncedgot time to show it? ❤️
I don't fully get what you mean
doesn't have to be today
like this works
and it's actually fairly clean i think
actually
with your approach
i won't have to do this
in the end to trigger db mutation right?
1. split your state management into one that is synchronised with the db and one that is not
2. make a deferred effect in which you'll read all of your state and send it to the db
3. you can split it into multiple effects if that's better
1. i get i think
2. thats with createEffect?
just so I understand the requirements
you only want to sync one todo at a time after it's been updated with that gql query where you target that todo by an id
I thought initially I would have to use
createResource
for this
so the reqs are
on load, load into todos()
global signal the state of all todos user has
thats done already
now
todos() is global signal
just do what I do now
mutate it etc
but on every mutation, in background it sends an update to db
so it persists
I have this now
but to do this
after every mutation to todos()
I have to do global.setRunMutateTodo(id_of_udpated_todo)
this is graphql mutation
it accepts an id
and the todo
values
what I do now in affect that listens to setRunMutateTodo
changes
like in my mind ideally
I wouldn't have to do this global.setRunMutateTodo(todo_id)
but then I realize
I need to know the updated id to do the mutation
I can run a .find or something though
or I dont know
not sure if Im clear with explaining 🙂
you can clone repo
and test it out
its pretty niftythis is why people need to learn mapArray
.map() you mean?
i love .map() 😄
nah
solid has a way more powerful one
actually keyArray not map but the same pattern
or maybe not 🤔
SolidJS
Solid is a purely reactive library. It was designed from the ground up with a reactive core. It's influenced by reactive principles developed by previous libraries.
fancy
but I don't see how that would be used
oh no
oh yes, dm'd to setup setup with you 🙂
ok @thetarnav is a legend
its solved fully now https://github.com/nikitavoloboev/kuskus/commit/730b95d308664c00ba544f0ace8c0cadbadeab26
GitHub
Sync and refactor todos store (#3) · nikitavoloboev/kuskus@730b95d
* Sync and refactor todos store
- moved todos into a separate store
- changed signal into a resource
- moved mutations to the store
- setup an effect syncing the state to the db (unfinished)
-...
@Jutanium btw this is a good example of using
mapArray
(keyArray actually but the concept is the same) to do something different than rendereing or deriving data
it reconciles the input signal, to let you sync the state on the client with the db through graphql calls
you have 3 different requests:
1. adding
2. updating
3. removing
which correspond to keyArray lifecycle:
1. mapFn is called for new item
2. effect subscribes to item rerun
3. onCleanup calledUnknown User•2y ago
Message Not Public
Sign In & Join Server To View