feat!: `react-query` and supplementary improvements #147

dalechyn · 2024-02-28T00:01:41Z

Will close #146

The main motivation being that with pnpm packages in the monorepo don't have to specify versions of the dependencies of other packages in the monorepo. It is also widely adopted across different monorepos. As well as `changesets` would replace the `workspace:*` marked versions on fly, so there won't be a need in managing those by hands (if there was one before). Fixes the lint issue, where in `with-next-auth` example a lint config was not properly set up, which caused the `lint` job to hang up waiting for stdin input. Adds a `turbo.json` config to `auth-kit` to depend on `auth-client`, as the build job for the first depends on the latter.

dalechyn · 2024-02-28T12:20:43Z

auth-monorepo/packages/auth-client/src/clients/transports/http.ts

Lines 87 to 89 in b5ad5ec

    
           const deadline = Date.now() + timeout; 
        
           while (Date.now() < deadline) {

This code seems incorrect as the Date.now() would be re-evaluated on the while clause check. Fixing it as well.

Moved the `Date.now()` to `now` variable to ensure the timestamp at which the polling started is preserved correctly.

dalechyn · 2024-02-28T12:28:31Z

auth-monorepo/packages/auth-client/src/actions/app/watchStatus.ts

Lines 19 to 31 in b5ad5ec

    
           export const watchStatus = async (client: Client, args: WatchStatusArgs): WatchStatusResponse => { 
        
             const result = await poll<StatusAPIResponse>( 
        
               client, 
        
               path, 
        
               { 
        
                 timeout: args?.timeout ?? 300_000, 
        
                 interval: args?.interval ?? 1000, 
        
                 onResponse: args?.onResponse ?? voidCallback, 
        
               }, 
        
               { authToken: args.channelToken }, 
        
             ); 
        
             return unwrap(result); 
        
           };

I believe this is a bit misleading, as we don't watch the status change here. In fact, the poll function which is used, polls until success, meaning that it doesn't return multiple values as an async generator would, but rather retries the request on not satisfying response with a certain interval until a deadline is met and watch is something that watches the value being changed over time.

I'm considering to refactor this as well.

dalechyn · 2024-02-28T13:07:33Z

auth-monorepo/packages/auth-client/src/messages/verify.ts

Lines 54 to 68 in b5ad5ec

    
           const validateNonce = (message: SiweMessage, nonce: string): AuthClientResult<SiweMessage> => { 
        
             if (message.nonce !== nonce) { 
        
               return err(new AuthClientError("unauthorized", "Invalid nonce")); 
        
             } else { 
        
               return ok(message); 
        
             } 
        
           }; 
        
           const validateDomain = (message: SiweMessage, domain: string): AuthClientResult<SiweMessage> => { 
        
             if (message.domain !== domain) { 
        
               return err(new AuthClientError("unauthorized", "Invalid domain")); 
        
             } else { 
        
               return ok(message); 
        
             } 
        
           };

Those methods should not return any value as they don't mutate it. Same concern addressed in validate.ts methods.

dalechyn · 2024-02-28T15:05:00Z

auth-monorepo/packages/auth-client/src/clients/transports/http.ts

Lines 87 to 89 in b5ad5ec

const deadline = Date.now() + timeout;

while (Date.now() < deadline) {

This code seems incorrect as the Date.now() would be re-evaluated on the while clause check. Fixing it as well.

Crap, just realized this is intended. Will undo in next commit.

It is a breaking change, since the hook APIs also change. However, everything is much more reliable now, and effects are not triggered when they don't have to. The context was changed to simply hold the `config`, which one has now to initiate with `createConfig`, in order to construct an `appClient`. The rest of the state now is handled by `zustand`, specifically, the `useProfile` and `useSignInMessage` use it.

.github/workflows/ci.yml

.gitignore

Dockerfile.relay

dalechyn · 2024-02-29T12:40:22Z

packages/auth-kit/src/components/SignInButton/SignInButton.tsx

+      if (
+        signInError instanceof AuthClientError &&
+        signInError.errCode === "unavailable" &&
+        signInError.message.startsWith("Polling timed out after")


could be a specific errCode

packages/auth-kit/src/hooks/useSignIn.ts

horsefacts · 2024-03-15T14:13:24Z

examples/with-next-auth/pages/index.tsx

-    [signIn]
-  );
+  const handleSuccess = useCallback((res: CompletedStatusAPIResponse) => {
+    console.log(res);


Suggested change

console.log(res);

dalechyn · 2024-03-24T21:22:14Z

I'm thinking about the implementation of useSignInMessage and useProfile hooks, probably they don't need to store the value from the response.

I believe it is a similar state management question as wagmi's connector handling.
Specifically, one could say that they could persist the return of the connectors between re-renders, but instead they have the autoConnect option that reconnects the providers (although they have cookie persistence to pass previous data until new one is hydrated https://wagmi.sh/react/guides/ssr#persistence-using-cookies).

Thus, I believe that useSignMessage should not be a client store but rather a function that re-uses query client cache to retrieve the latest used signing message.

For the useProfile – I believe it should be a query/a hook that retrieves data from the query client cache as well.

What has to be persisted though is something like a session token, optimistically with a certain deadline.

The current problem is that AFAIK the profile data is retrieved only from the pollStatusTillSuccess and is only returned in CompletedStatusResponse, therefore is only retrievable when a user undergoes through the QR Code authentication process.

What I believe should be done instead is that auth-relay should generate an access token for a user when one sucessfully undergoes the QR Code authentication, and auth-client should handle the creation of session tokens, their persistence and expiry.

With those changes applied, hooks for client data retrieval (optimistically useProfile) would not require a user to under-go QR flow, but would require an access token that might be persisted by auth-client or other client-side management implementations.

cc @horsefacts

dalechyn · 2024-03-31T22:23:51Z

TODO: Refactor use profile and use sign in message hooks.

useProfile should make a request to relay server to retrieve the profile as after a page refresh the data is lost.

useSignInMessage should take the data from query cache.

deodad · 2024-04-16T19:46:35Z

I'm thinking about the implementation of useSignInMessage and useProfile hooks, probably they don't need to store the value from the response.

I believe it is a similar state management question as wagmi's connector handling. Specifically, one could say that they could persist the return of the connectors between re-renders, but instead they have the autoConnect option that reconnects the providers (although they have cookie persistence to pass previous data until new one is hydrated https://wagmi.sh/react/guides/ssr#persistence-using-cookies).

Thus, I believe that useSignMessage should not be a client store but rather a function that re-uses query client cache to retrieve the latest used signing message.

For the useProfile – I believe it should be a query/a hook that retrieves data from the query client cache as well.

What has to be persisted though is something like a session token, optimistically with a certain deadline.

The current problem is that AFAIK the profile data is retrieved only from the pollStatusTillSuccess and is only returned in CompletedStatusResponse, therefore is only retrievable when a user undergoes through the QR Code authentication process.

What I believe should be done instead is that auth-relay should generate an access token for a user when one sucessfully undergoes the QR Code authentication, and auth-client should handle the creation of session tokens, their persistence and expiry.

With those changes applied, hooks for client data retrieval (optimistically useProfile) would not require a user to under-go QR flow, but would require an access token that might be persisted by auth-client or other client-side management implementations.

cc @horsefacts

I don't think we want the relays to become general purpose auth servers. Session tokens, and their persistence and expiry should be up to the developer and the auth setup they're using.

dalechyn · 2024-04-17T07:56:34Z

I'm thinking about the implementation of useSignInMessage and useProfile hooks, probably they don't need to store the value from the response.

I believe it is a similar state management question as wagmi's connector handling. Specifically, one could say that they could persist the return of the connectors between re-renders, but instead they have the autoConnect option that reconnects the providers (although they have cookie persistence to pass previous data until new one is hydrated https://wagmi.sh/react/guides/ssr#persistence-using-cookies).

Thus, I believe that useSignMessage should not be a client store but rather a function that re-uses query client cache to retrieve the latest used signing message.

For the useProfile – I believe it should be a query/a hook that retrieves data from the query client cache as well.

What has to be persisted though is something like a session token, optimistically with a certain deadline.

The current problem is that AFAIK the profile data is retrieved only from the pollStatusTillSuccess and is only returned in CompletedStatusResponse, therefore is only retrievable when a user undergoes through the QR Code authentication process.

What I believe should be done instead is that auth-relay should generate an access token for a user when one sucessfully undergoes the QR Code authentication, and auth-client should handle the creation of session tokens, their persistence and expiry.

With those changes applied, hooks for client data retrieval (optimistically useProfile) would not require a user to under-go QR flow, but would require an access token that might be persisted by auth-client or other client-side management implementations.

cc @horsefacts

I don't think we want the relays to become general purpose auth servers. Session tokens, and their persistence and expiry should be up to the developer and the auth setup they're using.

Yep! I figured it out a bit later and need to rename some things now.

I introduced changes to routes, data types and now I'm reverting it back

Reimplemented 1265f28.

dalechyn · 2024-04-17T23:25:55Z

I dropped e2e test in the merge conflict on purpose. tbh a bit lazy to rewrite it right now, that effort has to be put later on.

dalechyn · 2024-04-17T23:27:55Z

pipelines fail because I've changed the package manager.

dalechyn · 2024-04-17T23:28:41Z

tbh I have some questions regarding the dalechyn@62874a0 but we can think of this later if we want this pr to ever make it lul.

dalechyn · 2024-05-15T13:35:46Z

gonna separate the efforts in this fork: https://github.com/dalechyn/fc-auth, since the changes are too massive to be merged.

fix: Date.now() being revaluated in the poll function

69ac42e

Moved the `Date.now()` to `now` variable to ensure the timestamp at which the polling started is preserved correctly.

dalechyn changed the title ~~feat: react-query and supplementary improvements~~ feat!: react-query and supplementary improvements Feb 28, 2024

dalechyn marked this pull request as ready for review February 28, 2024 21:58

dalechyn and others added 2 commits February 28, 2024 23:59

Merge branch 'main' into improvements

075acaa

chore: changesets

626ead6

dalechyn commented Feb 29, 2024

View reviewed changes

dalechyn marked this pull request as draft February 29, 2024 01:29

fix: bad paths to pnpm lock file and ci

7b06f2e

dalechyn marked this pull request as ready for review February 29, 2024 12:38

dalechyn commented Feb 29, 2024

View reviewed changes

dalechyn commented Mar 15, 2024

View reviewed changes

packages/auth-kit/src/hooks/useSignIn.ts Outdated Show resolved Hide resolved

dalechyn commented Mar 15, 2024

View reviewed changes

packages/auth-kit/src/hooks/useSignIn.ts Outdated Show resolved Hide resolved

horsefacts reviewed Mar 15, 2024

View reviewed changes

wip: cleaning up auth-kit

6cb43f9

dalechyn marked this pull request as draft March 18, 2024 00:49

dalechyn added 4 commits March 18, 2024 17:51

wip: fix auth-client

6163e4c

wip

25b2761

wip

2483029

wip

b75beb8

dalechyn added 2 commits March 25, 2024 02:57

refactor: relay to use hono

4fc586c

refactor: channels -> sesisons

65f2bd5

horsefacts requested a review from tmm March 25, 2024 21:30

nit: tweaks

b1eb3f3

dalechyn added 6 commits April 17, 2024 23:32

refactor: rename sessions back to channels

8093323

refactor: bring back the old api

1d8e329

I introduced changes to routes, data types and now I'm reverting it back

nit: tweak

0c21b18

feat: fallback hub url

c76efc5

Reimplemented 1265f28.

feat: implement 62874a0 from main

39e0cf8

Merge remote-tracking branch 'upstream/main' into improvements

906520a

chore: lockfile fix

55afa21

dalechyn marked this pull request as ready for review April 17, 2024 23:28

dalechyn requested a review from horsefacts April 17, 2024 23:28

dalechyn closed this May 15, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat!: `react-query` and supplementary improvements #147

feat!: `react-query` and supplementary improvements #147

dalechyn commented Feb 28, 2024

dalechyn commented Feb 28, 2024 •

edited

Loading

dalechyn commented Feb 28, 2024 •

edited

Loading

dalechyn commented Feb 28, 2024 •

edited

Loading

dalechyn commented Feb 28, 2024

dalechyn Feb 29, 2024

horsefacts Mar 15, 2024

dalechyn commented Mar 24, 2024 •

edited

Loading

dalechyn commented Mar 31, 2024

deodad commented Apr 16, 2024

dalechyn commented Apr 17, 2024

dalechyn commented Apr 17, 2024

dalechyn commented Apr 17, 2024

dalechyn commented Apr 17, 2024

dalechyn commented May 15, 2024 •

edited

Loading

feat!: react-query and supplementary improvements #147

feat!: react-query and supplementary improvements #147

Conversation

dalechyn commented Feb 28, 2024

dalechyn commented Feb 28, 2024 • edited Loading

dalechyn commented Feb 28, 2024 • edited Loading

dalechyn commented Feb 28, 2024 • edited Loading

dalechyn commented Feb 28, 2024

dalechyn Feb 29, 2024

Choose a reason for hiding this comment

horsefacts Mar 15, 2024

Choose a reason for hiding this comment

dalechyn commented Mar 24, 2024 • edited Loading

dalechyn commented Mar 31, 2024

deodad commented Apr 16, 2024

dalechyn commented Apr 17, 2024

dalechyn commented Apr 17, 2024

dalechyn commented Apr 17, 2024

dalechyn commented Apr 17, 2024

dalechyn commented May 15, 2024 • edited Loading

feat!: `react-query` and supplementary improvements #147

feat!: `react-query` and supplementary improvements #147

dalechyn commented Feb 28, 2024 •

edited

Loading

dalechyn commented Feb 28, 2024 •

edited

Loading

dalechyn commented Feb 28, 2024 •

edited

Loading

dalechyn commented Mar 24, 2024 •

edited

Loading

dalechyn commented May 15, 2024 •

edited

Loading