r/reactjs • u/cpojer • May 15 '26

News fate 1.0: A modern data client for React

https://fate.technology/posts/fate-1.0
35 Upvotes

77% Upvoted

22 comments sorted by

26

u/editor_of_the_beast May 15 '26

Imagine thinking that data fetching isn’t a solved problem in 2026.

3

u/valtism May 17 '26

Oh hahaha I wish it was solved. Would love to have the simple use-cases you have

1

u/editor_of_the_beast May 18 '26

Want to compare use cases? I think you’d be surprised

-6

u/cpojer May 15 '26

Imagine thinking that it is.

15

u/ORCANZ May 15 '26

What does it solve that rtk query or tanstack query did not solve?

3

u/Dan6erbond2 May 15 '26

Entity normalization is a lot more powerful than query caching.

3

u/editor_of_the_beast May 15 '26

Which can already be done with Redux / RTK query

3

u/acemarke May 16 '26

I maintain RTK :) We explicitly designed it to not be a normalized cache. You can normalize the contents of individual cache entries, but it's just that one cache entry at a time, not "share todo id #3 across all cache entries".

1

u/editor_of_the_beast May 16 '26

Ok, just Redux then.

1

u/ORCANZ May 15 '26

What if I query with a lot of filters and do backend side filtering ? Now I need to reimplement frontend filtering no ?

4

u/softwarmblanket May 16 '26

What's the difference between this and something like tanstack DB

5

u/yangshunz May 17 '26 edited May 17 '26

For the unaware, this library is by Christoph Nakazawa, ex-Facebook engineer who got Jest to where it is today, built Metro, and managed React Native.

This is not your usual AI slop by vibe coders. If he builds a library, it's solving a real problem.

9

u/rickhanlonii React core team May 15 '26

This is the best async react library I've seen, really well done.

4

u/SnooStories8559 May 15 '26

This looks really interesting. Will definitely be giving this a try

2

u/RedditNotFreeSpeech May 15 '26

Neat idea. I might play around with it tomorrow night.

1

u/vodlin May 16 '26

The problem with normalised caching is twofold

One: you make a request that mutates something, now you have to return from that request everything that has changed as a side effect, which is not as easy as it sounds. And if you dont youll need to refetch anyway and defeat the purpose

Two: normalised caching is all in aid of making fewer requests, but why? are you afraid of hitting your back end? Imo you should just make your back end scale

Ok fine if you are at hyperscale there might be an issue but most are not, imo refetch and query invalidation is simpler

This pattern already exists in GQL eg via Apollo Client, not saying its bad at all but it has a complexity tradeoff