5 ms·

These are the options I have used and tested heavily (only in React): Redux: - pros: framework to place different pieces of logic, makes it predictable once e

These are the options I have used and tested heavily (only in React): Redux: - pros: framework to place different pieces of logic, makes it predictable once everyone is onboarded; boilerplate (actions, reducers, selectors, etc) makes it easier to avoid mistakes if you're not using TS - cons: boilerplate adds a lot of friction that's not needed if you're using TS; debugging usually requires jumping through more files XState: - pros: what I said for Redux but on steroids - cons: big setup (learning-wise); feels overkill 95% of the time Context: - pros: simple to understand and use (you expose values and setters via useContext); minimal setup (Provider and useContext) - cons: you're still trapped inside React, your logic is inside a big component by default Mobx: - pros: keeps your logic out of React by default; you can export your model to another env and debug/test/play easily - cons: most costly to setup (learning, config) out of all the options (redux with starter toolkit reduces the setup overhead) I mainly use Context now as I port from Redux. Feeling the pain of not having an interactive model outside of my app views and want to get my team on Mobx.

jrvarela56 4y ago
If you think this is convoluted or overly complex (I see a lot of 'just use Javascript and DOM APIs') think about it for a second: how many libraries do you load in your backend projects? We have a lot of dependencies related to state management (database, ORM, caching solution, task queue, etc) - it's a big problem. Why wouldn't we use tooling to make our lives easier in JS/TS frontends?
- doodlesdev 4y ago
  Because the backend actually does something. Truth is 99% of frontends are just a way to display data just fetched from the server and don't really have a need for state management at all. For the 1% out there, use Redux (or Redux Toolkit), or maybe forget about React since it's not the only library ever invented.
  - jrvarela56 4y ago
    How would you develop a web app that needs to work offline?
    - doodlesdev 4y ago
      You could very easily handle storing to localstorage or indexeddb using stores. However, in larger projects that can become error prone and increase complexity (unnecessarily). To simplify this workflow you could use something like https://github.com/andsala/svelte-persistent-store https://github.com/andsala/svelte-persistent-store Note that repo is basically 50 lines of code to automate this stuff, which is pretty remarkable. However this still won't handle cache invalidation or syncing. https://sveltequery.vercel.app/ https://sveltequery.vercel.app/ should handle most use cases. This is very similar to React Query (since it's from the same devs at https://tanstack.com/ https://tanstack.com/). For handling the service workers stuff for (what I assume would be a PWA) I'd just use the Vite PWA plugin which uses workbox. That's if I need a service worker at all, if I don't I'd just set the manifest and be done with it. An alternative depending on the needs of the specific project is to just fallback on something like the Firebase or Supabase SDK which handle offline mutations and syncing for you, for simpler projects these work incredibly well.
  - qudat 4y ago
    > Because the backend actually does something. Yikes. We can be just as reductionist about the BE: it’s just a shim for accessing a database.
    - doodlesdev 4y ago
      For most CRUD apps it is, that's why we can have things such as Firebase which is essentially just a layer between the frontend and database, with some security rules and you're done. Most developers overengineer to the extreme their projects. I'm not saying all of them are like this, or that all applications are just simple CRUDs, but most are.

jrvarela56 4y ago

If you think this is convoluted or overly complex (I see a lot of 'just use Javascript and DOM APIs') think about it for a second: how many libraries do you load in your backend projects? We have a lot of dependencies related to state management (database, ORM, caching solution, task queue, etc) - it's a big problem. Why wouldn't we use tooling to make our lives easier in JS/TS frontends?

doodlesdev 4y ago
Because the backend actually does something. Truth is 99% of frontends are just a way to display data just fetched from the server and don't really have a need for state management at all. For the 1% out there, use Redux (or Redux Toolkit), or maybe forget about React since it's not the only library ever invented.
- jrvarela56 4y ago
  How would you develop a web app that needs to work offline?
  - doodlesdev 4y ago
    You could very easily handle storing to localstorage or indexeddb using stores. However, in larger projects that can become error prone and increase complexity (unnecessarily). To simplify this workflow you could use something like https://github.com/andsala/svelte-persistent-store https://github.com/andsala/svelte-persistent-store Note that repo is basically 50 lines of code to automate this stuff, which is pretty remarkable. However this still won't handle cache invalidation or syncing. https://sveltequery.vercel.app/ https://sveltequery.vercel.app/ should handle most use cases. This is very similar to React Query (since it's from the same devs at https://tanstack.com/ https://tanstack.com/). For handling the service workers stuff for (what I assume would be a PWA) I'd just use the Vite PWA plugin which uses workbox. That's if I need a service worker at all, if I don't I'd just set the manifest and be done with it. An alternative depending on the needs of the specific project is to just fallback on something like the Firebase or Supabase SDK which handle offline mutations and syncing for you, for simpler projects these work incredibly well.
- qudat 4y ago
  > Because the backend actually does something. Yikes. We can be just as reductionist about the BE: it’s just a shim for accessing a database.
  - doodlesdev 4y ago
    For most CRUD apps it is, that's why we can have things such as Firebase which is essentially just a layer between the frontend and database, with some security rules and you're done. Most developers overengineer to the extreme their projects. I'm not saying all of them are like this, or that all applications are just simple CRUDs, but most are.