This is my introduction to the word "Expensify". I assumed it meant something like "enshitify" eg: "enshitification".

It's an odd name. Nice of you to share on Github.

It's a brand name, for everyone's context.

I find it interesting to read these UX patterns and ask myself "would the same UX pattern work for a local-first application?".

I find that in most cases, a local-first application would have a more predictable UX, because most actions need to be successful without a remote server to begin with.

Still, building the UX with an "offline-first" mindset is a giant leap forward when compared to all the networked applications I interact with.

And yet as a user I sometimes find local-first applications harder to reason about. For some apps I know to force-quit and relaunch the mobile app after reconnecting to the network before opening the website, for example.

Distributed systems are just hard I guess, especially involving user systems.

Local-first applications are much harder to reason about than server-driven apps or local-only apps, because there's now two sources of truth - the app and the server. Reconciling the two is much trickier than it looks.

This is my first time seeing Expensify's extensive open source work. Pretty cool and rare. Were they always open source? Anyone understand the strategy here or used the new App?

I know that Expensify is one of the highest-ticket supporters of SQLite, because they (at least at one point, and probably still) have what is probably the world's largest SQLite database powering everything they do.

As a big fan of SQLite myself, I have to admit, this significantly raised their street cred in my eyes.

From casually browsing their GitHub, it seems that only their frontend is open source. I couldn't find the backend anywhere.

I’ve known them through their work on Wish List and Flash List. They’re one of the bigger supporters in work on list rendering in React Native (a vital, devilish, and often overlooked area).

I loathe the over-abundance of "Optimistic Without Feedback Pattern". It is used as a crutch for "I don't want to bother implementing error cases". Even the pinned chat example they use is just a bug factory. Stating "this particular API request has almost no way of failing, and we know what the server will return in advance" is extremely naive. The user could have gotten logged out somehow, or maybe there's a rate limit or something, or the server's overloaded, or they're offline and going to use the app on another device that is online before you can sync, or whatever.

Assuming the happy path just leads to the app breaking in weird ways down the road.

What are the other options?

handle the errors, ideally manually

What error?

The same options we've had literally since computers were invented. Unexpected and unrecoverable errors are as old as computing. This is not some new field of rocket surgery.

You use whatever mechanism is available in your language/framework to catch exceptions or errors, and you handle it. The program should do its best to recover, fail gracefully, and emit a useful message or log.

This is one of the core tenets of programming. Again, since the dawn of time.

> The user could have gotten logged out somehow, or maybe there's a rate limit or something

All your examples are retryable errors in which the prescription is the same: "keep the message queued until it's successful." And when all your failure modes are like this optimistic-no-feedback works. If you have non-retryable errors in your failure modes "Bad Request", "Gone" this pattern can't be used.

Not being logged in is not a retryable error.

Sure it is, why wouldn't it be? Keep it stored and queued until they log in again. It's the same as being offline.

What if someone else logs in?

Your local storage, and hence the queue, isn't segmented by user?

Sure they're retryable. But those retries might never succeed (user wipes their phone or uninstalls the app or logs out or clears local app data or a buffer fills up to come up with a few scenarios. Either the request didn't matter to the user at all, in which case sure whatever, or at some point they're going to discover that the thing they thought happened didn't actually happen.

My error buckets and //TODOS with dreams of more refined implementations weren't all that lazy after all.

So what you are saying is that you don't think apps should work when offline?

Not at all. I'm saying that they should reflect the unereliability inherent in distributed computing rather than pretend it can't exist with such false notions as "retries will fix it" or "this call can't fail"

The names of patterns are extremely useful when you want to express to your coworkers "just update the view first and revert if the API fails" concisely.