(i haven't looked fully at code) but is there a reason you cant just make everything an input and use server actions to submit instead of this large client side state

as then it will be already in formData

tbh shame on me, but i never read deep into formData itself, and just wondering now, what makes more sense right now, if it even makes sense to do it via Formdata, or just continue to use the States with the contextprovider

well what do you do with your data after submit

does it just get sent to endpoint to only get back via another request

it gets written in the MongoDatabase, with some additional data added for identification

yeah this sounds like perfect use of server actions with form

as the additional info can be in hidden input

But what i have to think about, if i could "presave" the data on the client, if there is no network connection.

you can still add defaults to the input

also you can still have the client hooks

but this way with normal form, it will submit normaly + work with js disabled for those who are weird or bad device

So the data is not going missing, if there is no connection in the event of submitting, but i think i may can create a clause, which checks if there is any connection possible if not, safe to localstorage and trigger an event, when it get connected again

ahh i see what you mean there

but how likely is your app going to be in that weird pos? (just wondering... idk your target market)

50/50 i would say, as the worker has to take these in the basement of houses/industries, and there is a good change no network connection is possible

oh yeah thats important

hmm i think you could do a server action but then custom onsubmit event where it tried to submit... if failes tries to string the formdata to be tried again soon

The app, is for electircal workers which have to take measurements of electrical installations, which then need to be sent to the gouverment. so if there are some measurements gone lost, it would mean the worker has to redo every measurement which can take up to a day to to it propperly, i also thougt about partial upload of data, but i think it would also clutter my db with nonsense.

yeah i can see why state is needed now

can i ask if the user will have many tabs open, or just their one

im not going to ask if they close it, because lots of browsers are bad with state when you close the app 😭

i thought about writing all in a context, and cosafe it to the localstorage, in case of anything gone wrong, and upload it when its possible, and remove it then from the storage, but idk how that works with DSGVO and shit like that

Usualy i hope just one tab LMAO

and how would you retry submit

on next page view check localstorage and then submit

maybe a silent ping request to a specific API request? and if successfull, upload the data in the background and create a notification for the user, that the data has been uploaded.
Idk tbh as i also slowly think the project get to large for me xD

also is this page an offlineable site making use of web-worker

Yes it the plan in the long therm, i have implemented the PWA, but i may have to wait for Apple and co to see what they're doing about it, or what Apple perse does whith opening the app store here in the EU,

i also thought about just creating the Web version, and go for Expo or something to do it native on Andorid and so on, but the overhead and complexity is just to big for my peanutbrain

oh do you operate in eu 😭

that would be also somewhat of easy to refactor the code Thanks m8. If i get paid sometime i will buy you a coffe 😄

Switzerland, so even more complex as the EU shit....

ahhh well best of luck then

i hope i have given you some things to think about

Yes Sir ❤️

i was going to make a native app for my email thing, as i kinda saw how good nextjs in browser was and how every borser was liking things likc push notifs... but now idk

i still have Tauri in my back of the head, and will look into it maybe, but CSR is just somewhat of weird in todays standards

and i think pwa with maybe one hook (as you can have dict) could be the best thing for you as offline is important

but server side is also nice these days too

you say 50/50 with internet, so i don't want them to loose internet and crash phone and now no page

maybe wasm is also an alternative to run the background task in rust as a native "module" extra for phones, idk i will have to learn to read and then read some docs and apis about it, as phones can be weird in theire behaviour

i think going into wasm for this is a little far... id say focus on shipping thing than go chaos into imor speed improvements

its not like you are rendering complex thing on device

true

(also i have heard v8 can be faster than wasm as its so optimised in some cases)

i just learned that SWR is a good friend of mine nowdays...

ah yes swr is nice with client side fetching

something looks wrong here tho... why axios when fetch is there and better (esp on browser) https://www.adios-axios.com/

i had some time ago a "bug (mostly i was dumb)" which i just switched to axios, im currently rework every request, to its coressbonding file, so changes or updates of api routes are easier to maintain... i am learning everyday as im just a hobbyist who is also dumb af 😛

server actions are so much extra nice as you don't need to make fetch req... it just does it when you use function

and thus you can still swr it

'use client';
import useSWR from 'swr'


const fetcher = url => axios.get(url).then(res => res.data)

export function useGetNivByUserID(uuid) {
    const { data, mutate, error } = useSWR(() => `/api/niv?userid=${uuid}`, fetcher)
    const loading = !data && !error;
    // console.log(loading)
    return {
        loadingGetNiv: loading,
        nivData: data?.result?.data,
        nivError: error,
        mutate
    };
}


export function useGetNivByUserUUID(uuid) {
    const { data, mutate, error } = useSWR(() => `/api/niv?id=${uuid}`, fetcher)
    const loading = !data && !error;
    // console.log(loading)
    return {
        loadingGetNiv: loading,
        nivData: data?.result?.data,
        nivError: error,
        mutate
    };
}

so not the best idea? 😄

true could now change it to native fetch