redux-essentials-example-app VS Dexie.js

You're right, it is related. But I think that Flux- and ELM-like architectures are making it even worse by forcing any "external" interaction to became the gap. Look how they suffer when it comes to executing any async operation like network request. Initially we have this relatively simple framework, but then we had to add "Middleware" to just run network request (which is a good example of the Remainder issue). I love the idea behind these architectures, which makes logic more predictable and testing way easier. I even was using them by myself. But now they looks like something turned inside out for me. I believe we could do better. I'm finishing my proposal right now. It will take couple more weeks to edit and translate it, but soon I'll show what I mean.

Hi, I maintain Redux and wrote most of our docs (including our current tutorials).

Can you give some details on which parts of our docs you feel are "incomprehensible"? I'm curious which specific pages you've been looking at, and for what purpose.

We've tried to organize the docs using the "Documentation System" approach described at [0]: Tutorials for teaching step-by-step, Explanations and How-To guides for specific topics, and References for API details.

Generally we want people to go through our "Redux Essentials" tutorial [1] as the primary way to learn how to use Redux correctly. It teaches "modern Redux" patterns with Redux Toolkit as the standard way to write Redux logic (including RTK Query for handling data fetching), and React-Redux hooks in components.

I'm genuinely interested in feedback on what explanations aren't clear and how we can improve things!

[0] https://documentation.divio.com/

[1] https://redux.js.org/tutorials/essentials/part-1-overview-co...

https://redux.js.org/tutorials/essentials/part-1-overview-concepts (covers how to use Redux Toolkit and RTK Query)

Dexie.js

The word on the street is that https://github.com/rhashimoto/wa-sqlite is nearly production ready, closing in on the neat 1.0.0 release, with its IDBBatchAtomic engine highly recommended at https://www.powersync.com/blog/sqlite-persistence-on-the-web. You can try out the benchmark https://rhashimoto.github.io/wa-sqlite/demo/benchmarks.html.

And the other contestant is Dexie, stable https://dexie.org/.

If you were to branch into a new venture today, which one would you pick? And why?

That said, there are some great ways to wrap IndexedDB to make it easier to work with. Since I’m writing this article I’ll toss in my local-first framework Verdant, which can be used without the sync features as a standalone IndexedDB-powered database with a type-safe schema and deployable data migrations. For a lighter-weight approach, maybe check out Dexie.

Using IndexedDB. I have heard its pretty cumbersome to use. There are wrappers like Dexie.js but I am not sure if it works seamlessly with Tauri or if it is the correct thing for my use case.

I use IndexedDB, specifically the idb library (https://github.com/jakearchibald/idb), or Dexie.js (https://dexie.org/) if you are more novice. This works great for large sets of data. For smaller amounts, Chrome Storage API will do.

To make things easier, Dexie.js provides a straightforward and simplified process of creating databases, storing data, updating data and database migrations, etc., over the top of indexedDB.