-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[APP-243] feat: revive monorepo #2
Conversation
This is work in progress. The proposed monorepo change would allow us ship both CJS, ESM and DTS files split in different proxy packages for better tree-shacking purposes. As well as it "fixes" (and ignores) some of the issues within the `core` package, and yet needs more type-safety fixes on `react` package.
Size Change: 0 B Total Size: 109 kB ℹ️ View Unchanged
|
Size job fails but should be operating normally after the merge. Post-action bug in there. |
examples/wagemos-app-nextjs/src/app/_components/connect-button.tsx
Outdated
Show resolved
Hide resolved
const { | ||
data: wagemosQueryClient, | ||
isLoading: isWagemosQueryClientLoading, | ||
isError: isWagemosQueryClientError, | ||
error: wagemosQueryClientError, | ||
} = useModuleQueryClient( | ||
{ | ||
moduleId: WAGEMOS_MODULE_ID, | ||
Module: WagemosAppQueryClient, | ||
}, | ||
{ enabled: options?.enabled }, | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we should also pull this into an autogenerated hook useWagemosQueryClient
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you describe a bit more what do you mean?
}, | ||
}) | ||
|
||
export type AbstractProviderProps = AbstractConfigProps |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably allow the consumer to provide query client options as well - this is what graz does https://github.com/graz-sh/graz/blob/2dd73ddae3313e76be5f79215a30c0916c9c1fcd/packages/graz/src/provider/index.tsx#L2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or a client should instead init the query client on his side and inject it into the provider, we could build a fancy createConfig
as wagmi did.
Also commented out the dev build for the package, since nextjs example tries to transpile it and requries dependencies to be installed.
Unfortunately I am meeting building issues again.
Turned out to be a bad remapping to the package path.
Still having return type annotations issues.
It turned out that `tsup`s `dts` flag has been generating incorrect typings, so I tried using `experimentalDts` and it worked. `react` package won't use this option though, since it doesn't work there. DTS building is a wild world.
@adairrr lint, build, types jobs pass. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's get this merged and we can fix the remaining chain comments afterwards!
const onSubmit: SubmitHandler<z.infer<typeof placeBetSchema>> = useCallback( | ||
async ({ amount, accountSeq }) => { | ||
const accountIdToBetOn = round.teams.find( | ||
(account) => account.seq === +accountSeq, | ||
) | ||
if (!accountIdToBetOn) throw new Error('Account not found') | ||
|
||
await placeBetAsync?.({ | ||
msg: { | ||
roundId: round.id, | ||
bet: { | ||
account_id: accountIdToBetOn, | ||
asset: { name: round.total_bet.name, amount: amount.toString() }, | ||
}, | ||
}, | ||
}) | ||
|
||
setIsOpen(false) | ||
toast({ | ||
title: 'Bet placed', | ||
description: `You bet ${amount} ${round.total_bet.name} on account ${accountIdToBetOn.seq}`, | ||
}) | ||
}, | ||
[placeBetAsync], | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit small design question :
Is this generally the best way to deal with mutations in react-query? From what I've seen we want to avoid using the async mutation and add additinoal mutations in the components with the onSuccess and onError handlers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While react-query allows both, I assume it is safe to use both variants unless the post-mutation logic is triggered more than once.
This is work in progress.
The proposed monorepo change would allow us ship both CJS, ESM and DTS files split in different proxy packages for better tree-shacking purposes.
As well as it "fixes" (and ignores) some of the issues within the
core
package, and yet needs more type-safety fixes onreact
package.Implements APP-243 (https://linear.app/abstract-sdk/issue/APP-243/refactor-the-current-sdk)