search

paritytech / capi-multisig-app

[WIP] Simple multisig administration
https://multisig.capi.dev/
Apache License 2.0
8 stars 0 forks source link

Investigate alternatives to React Query #222

Open statictype opened 1 year ago

statictype commented 1 year ago

The experience is too slow. Even if the proposals are updated after finalization, it takes 20+ seconds for the UI to update every time.

Not clear how the caching and automatic refetching help us in a blockchain context. Seems like none of React Query's promises actually work for our use cases

peetzweg commented 1 year ago

Not to sure what the issue here is. react-query does refetch any data on it's own, only once it becomes "stale" after a given time. You can manually refetch a given query with the refetch function returned by useQuery/useMutation like I do here:

https://github.com/paritytech/capi-multisig-app/blob/2698940b42891a223e82a9d579f6e5879c8601fd/www/src/components/Setup.tsx#L30

Another way is also to invalidate certain query keys, which makes the data of a query state and triggers refetching. https://tanstack.com/query/v4/docs/react/guides/query-invalidation

I don't see any reason why react-query wouldn't work in our usecase. I've built a whole ethereum app only using onchain data with react-query without any issues.

Remember, only when the block is finalized the state changes is reflected in the data on chain, so refetching for a block submission or in block event does not change any data on chain. So refetching to early will result in the old same data as the state transition on chain hasn't happened yet. 🤷

statictype commented 1 year ago

i find the api pretty ugly tbh. i guess it's a matter of preferences. most annoying for me is that it requires us to handle data fetching on the component level, which is not the best practice imo. I agree it's a nice tool for basic REST and GraphQL needs, but for Substrate queries and transactions feels a lot like an overkill

Remember, only when the block is finalized the state changes is reflected in the data on chain, so refetching for a block submission or in block event does not change any data on chain.

this is why we need to update the UI precisely when finalization happens and I don't see a way to make React Query aware of that. i strongly feel like a custom solution is preferable here.

I've built a whole ethereum app only using onchain data with react-query without any issues.

but many other people have build dapps without it just fine... :)

I know how you feel about this, but given our workflow - showing updates on block inclusion but also waiting for finalization to refetch and confirm / revert previous updates - i'd like to have more flexibility than React Query offers.

Will work on this myself and I'm positive i'll come up with a solution that satisfies us both.

peetzweg commented 1 year ago

Don't forget that react-query does also a lot more than just doing as simple fetch for us, it does retries, error handling, loading/idle states handling and caching as well. Furthermore you can add stale time so it updates automatically. I think it's very powerful and would make a global state management lib obsolete as one could just reuse the queries in several components and the query data is either refetched or loaded from cache.

It's also does not care about rest or graphql it just handles a async function. Once the queries and mutation are bundled in a hook reusing the data throughout an app is also very pleasing. We would have hooks like useAccountInfo & useRatify instead of exposed useQuery and useMutation.

But happy to learn about alternatives and what they have to offer or maybe a custom solution built by us. ✌️