SQLite gives you just the "data fetching" part. But if you're building a React/RN app, you probably also want everything to be automatically observable.

For example, if you have a todo app, and you mark a task as done, you'd want the task component to re-render, the list to re-render (put the task at the bottom), and update the right counters (the counter of all tasks, and a counter of all tasks in ta project), etc. I hope you're getting the point.

Watermelon is an observable abstraction on top of SQLite (or an arbitrary database), so that you can connect data to components and have them update automatically

Thanks for this concise example! This helped me to understand why I should try it out, and led me to demoing this myself. I'll report back my findings

So is it fair to say its a React specific ORM, that automatically makes the mapped objects observable (an OORM, if you will)? Just trying to understand the level of abstraction that you're going for.

That's a fair description, yeah!

Does that mean that if user A makes an update to the database, then user B (on a different computer) will see the update?

No, Watermelon is a local app database. But you can plug it into a sync engine to synchronize with the server (and then from the server to another device) — it's up to you

Because it's very cumbersome, interfacing between Javascript and SQLite, and mapping between database records and Javascript objects. And it doesn't easily fit with the React way of doing things without some library to abstract away all the wiring.

I started building a hybrid mobile app (not React) with a large SQLite database about 4 years ago and have kept working on it ever since, and I've found the data storage aspect of the app very painful to maintain and extend.

I'm now starting to rebuild it using React Native, and a storage plugin like this could be perfect.

I'd been looking at Realm, but haven't gotten as far as committing to it yet, so I'll take a close look at WatermelonDB too.

I'm not buying the "too cumbersome to use SQLite" argument.

This still seems like a large unnecessary abtraction.

Sincere question: do you much work in React/React Native with large SQLite databases or other large data stores?

As the sibling (and better) comment[1] to my original comment points out, this library makes the data automatically observable throughout the React app, making it much simpler to update views in response to database changes.

I can understand you might not understand the value of this if you hadn't done a lot of work with React apps that have large data sets and where data changes need to be reflected in multiple different views.

[1] https://news.ycombinator.com/item?id=17958822

Why don't you try linking react with a large Sqlite, and later build a wrapper of your own, and then release it in HN next year as, pinappleDB?

Looks like it's mostly to provide a lazy loading wrapper for SQLite to React

Because then you don’t get to reinvent the wheel.

It's easy to be cynical on HN, but to the best of my knowledge, no other solution for React Native checks all the boxes we need.

And it's not like reinventing the wheel (it still uses SQLite), more like inventing better suspenders for the whole undercarriage ;)