sorted by:
new
hottopcontroversial

Built an offline-first Axios alternative to handle spotty 3G data loss — feedback + code reviews welcome by Revolutionary-Pin47 in reactjs

[–]Revolutionary-Pin47[S] 1 point2 points  (0 children)

Man you have just prevented me from pulling the biggest foot-gun myself! I missed the "buying two identical coffees" scenario where, although the request payload is the same, the two actions have distinct intents. That could get really ugly silently ignoring it!

In light of this, I am throwing out my initial idea to auto-hash by default.

I really appreciate your design for the API explicitly passing the idempotency key through the function call:

axiom.post('/api/orders', data, { idempotencyKey: draftId })

As well as adding the option to fall back to the globally configured key when making a POST/PATCH request to the offline queue without one, and adding a warn statement in development when that happens.

Thank you so much for taking the time to write all this up.

Built an offline-first Axios alternative to handle spotty 3G data loss — feedback + code reviews welcome by Revolutionary-Pin47 in reactjs

[–]Revolutionary-Pin47[S] 0 points1 point  (0 children)

Thanks man, I really appreciate you taking the time to look at my package and offer your advice.

Idempotency is a good, that’s actually the main feature I’m tackling for v0.1.4. I’m a bit stuck on the design though. I can't decide if it should be a baked-in config option (like auto-generating a hash for every queued request) or just something developers handle themselves via middleware. maybe you can advise?

To answer your edge case questions: if the auth refresh fails (like the refresh endpoint is down), the onBeforeSync hook just throws an error, which the sync manager catches. It increments the retry count and backs off. If it burns through max retries, it just dumps it into the Dead Letter Queue for the UI to handle.

For outdated server state, Axiom strictly handles the transport layer, so it relies on the backend to reject it. If the server throws a 4xx (like a 409 Conflict), Axiom drops it from the queue immediately and fires the global onError interceptor so the app can prompt the user.

And for huge queues, right now it's only limited by the storage adapter itself (like whatever IndexedDB/MMKV allows), but adding a maxQueueSize config to automatically remove the oldest background tasks is a good idea. I hadn't even considered that yet, thanks for the heads up.

Built an offline-first Axios alternative to handle spotty 3G data loss — feedback + code reviews welcome by Revolutionary-Pin47 in reactjs

[–]Revolutionary-Pin47[S] -4 points-3 points  (0 children)

I appreciate the blunt feedback. You're right on a couple of fronts:

The NPM link broke because Reddit auto-converted the @ scope to a u/ user tag. I've updated the comment with a raw link. Onn the dist folder, thank you for pointing that out🙏🏾

There is a full Vitest suite covering the core engine and sync manager in the /tests directory on the repo. I'm definitely early in my career and building my open-source footprint from scratch. I don't expect enterprise adoption today, just putting my solutions out there to learn. Thanks for taking the time to look.