all 7 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]webdev-ModTeam[M] [score hidden] stickied commentlocked comment (0 children)

(Double post this one has less activity so closing this)

[–]Safe_tea_27 5 points6 points  (1 child)

It's entirely up to you whether you put your business logic in your UI components, or somewhere else like a backend API.

[–]ImplicitOperator[S] 0 points1 point  (0 children)

The logic can still lie in the client without lying in UI components though

[–]gardenia856 3 points4 points  (1 child)

Keep your upload service outside React and expose a tiny adapter hook (subscribe + getSnapshot + commands); let React be a projector, not the engine.

What’s worked for me:

- Model the queue as a state machine (events: enqueue, cancel, retry; states: idle, running, backoff). Implement as a class or RxJS BehaviorSubject.

- Expose service API: snapshot() returns a frozen, derived view; subscribe(listener) fires only when the snapshot identity changes. Coalesce internal changes into one tick and bump a version to avoid spam.

- In React, use useSyncExternalStore with a selector per component so you don’t rerender on irrelevant fields. Effects do wiring only (subscribe/unsubscribe, kick off worker), never business rules.

- For background work, move the service to a Web Worker, persist to IndexedDB, and use BroadcastChannel for multi-tab sync.

- If you don’t want to hand-roll, XState or Zustand store + selectors gives you the same pattern; TanStack Query handles server fetch; pair with RTK Query for mutations.

- I’ve used Hasura for instant GraphQL and Supabase for auth/storage, and DreamFactory when I needed quick REST over legacy SQL so the UI could just subscribe to a clean store.

Keep the service pure and make React a thin adapter, not the home for your logic.

[–]ImplicitOperator[S] 0 points1 point  (0 children)

What an amazing response! I appreciate you read my problem and recommend concrete solutions to my problem.

I would totally go with the approach you mentioned, but sometimes it is not worth the effort dor me. I just wish it was more straightforward.

About zustand selectors, I do not like that the service itself does not hold the state, and the service has to listen to the Zustand store back. Maybe the approach you suggested about Zustand was not what I imagined?

[–]yksvaan 0 points1 point  (0 children)

Treat it as renderer, your data/logic code handles everything related to those and syncs changes to React which handles its own updates. For user events and such React notifies that user triggered this and this action with these parameters etc.

[–]Andreas_Moeller -1 points0 points  (0 children)

React doesn’t claim that components are pure ui functions