
Show HN: Redux Offline – Build Offline-First Apps for Web and React Native - thekenwheeler
https://github.com/jevakallio/redux-offline
======
acemarke
Neat example of the kinds of things that Redux helps make possible (or at
least more feasible).

If anyone is interested in learning Redux, I keep a big list of links to high-
quality tutorials and articles on React, Redux, and related topics, at
[https://github.com/markerikson/react-redux-
links](https://github.com/markerikson/react-redux-links) . Specifically
intended to be a great starting point for anyone trying to learn the
ecosystem, as well as a solid source of good info on more advanced topics.

I also maintain a catalog of Redux-related addons and utilities at
[https://github.com/markerikson/redux-ecosystem-
links](https://github.com/markerikson/redux-ecosystem-links) , which lists
things like middleware, store persistence management, pre-built logic for
managing collections of data, logging/linting devtools, and much more.

------
matmo
Slightly off topic, but how do people manage state that aren't using Redux?
When you google "redux alternatives", you typically get results for different
flavors or variants of redux. But are there other fundamentally different
paradigms for managing state? I love Redux, but I'm really curious what else
is out.

Also, the optimistic updates with rollbacks in this implementation is pretty
neat.

~~~
jasdeepsingh
I've been using Mobx very successfully on many of my projects now (both React
& React Native). I'll prefer Mobx any day over Redux, just due to it's sheer
simplicity and ease of use. Read: No need to burden your brain with the
cognitive load of actions, reducers, dispatching actions, selectors etc.

Mobx v/s Redux does kick off the OOP v/s Functional debate, but as a developer
my productivity and effectiveness is measured in terms of my ability to ship
software not in terms of my programming style, and it's my personal belief
that Mobx does make me more productive as compared to Redux.

For developers new to the whole Flux/Redux/Mobx/State Management world, I
highly suggest to give Mobx a try.

~~~
Kiro
Do you pass the MobX stores down to every child component as props or do you
use @inject? I started with the former but all of a sudden all my components
had all these "default" props that cluttered things up. @inject seems great
but the documentation doesn't push it enough to make me believe it's best
practice.

~~~
rawrmaan
Neither. Just import a singleton root store and reference it directly.

------
tonyhb
This looks pretty solid, and the ability to create our own resolvers makes
things much more flexible.

Currently creating a cross-platform react native app using realm.io for
persistence. While it's is great, the debugging performance is slow (rerouted
RPC calls) and it has a few quirks (each model is a proxy, odd optional field
support, poor error messages when data is erroneous).

The benefits of this seem to be:

1\. Pre-created retry logic, optimistic update logic

2\. Less effort to save data to realm

3\. Less effort to load data from realm on app reloads

4\. Potentially shared actions across our apps/web projects, as there's no
realm specific abstraction in our apps.

Gonna have a look at implementing this one day soon to compare and learn :)

------
WA
Please note: This is certainly a very helpful library, but it's made to work
with some kind of server/API. The defaults assume you get a connection again
within one hour. Obviously, you can tweak the defaults.

But if you want to build an app with its own real functionality that has sync
added (like a TODO list that syncs with other devices) and is entirely
offline-first where you can go _weeks_ without a connection, you better keep
searching. Maybe have a look at PouchDB.

~~~
tarr11
Other than Couch/Pouch, are there any other projects providing solutions to
this problem? The one thing I dislike about couchdb is the default "user-per-
db" model.

I'm interested in solutions that allow a traditional relational db instead of
a key-value store. Seems like with indexeddb on the client, and postgres on
the server, you could probably keep a segment synced.

~~~
WA
I haven't found one and I really wonder if everybody rolls their own sync
solution.

> _The one thing I dislike about couchdb is the default "user-per-db" model._

Why exactly? I think the overhead of the DBs is rather small. It's not like
having a MySQL DB for every user ;)

Also, you can achieve something like "global data" as well: Either replicate
from users' DBs to a shared DB or maybe make some kind of "system" user that
has access to the users' DBs. I'm not an expert, but that's what I figured out
so far with my limited experience.

~~~
tarr11
Performance-wise, i think it's probably fine. But it doesn't play well with
any kind of group permissions. Things are either owned by a user or they are
almost impossible to sync.

Let's say you are making a CRM with couch/pouch. Let's say that you have
permissions to see a Customer record, but it is shared across your company.
How do you sync that? It's not owned by a user, it's owned by the company.
What happens if permissions change?

------
LAMike
I'm re-learning Redux now, does anyone else think that it might be overkill
for an app that doesn't require any user input?

~~~
mercer
Quite possibly, and it's always a good exercise (and in this case justifiable)
to do it the 'vanilla way'.

That said, even for relatively simple, non-input type projects I've found that
Redux is worth it. I got thoroughly sick of passing props down multiple
levels.

Furthermore, I found that I often ended up making mistakes where my components
were too reliant on their context (even when considering variable/prop
naming). Redux, I feel, extends the 'pit of success' effect that React has;
when I use it I'm more likely to properly isolate components.

