Boilterplate app using React and Rust-compiled WebAssembly
Update README.md
Update README.md
Update README.md
Update README.md
Update README.md
Update README.md
Update dependency: typescript@4.9.4
typescript
Update 5 dependencies
@trpc/next
@trpc/client
@trpc/server
@trpc/react-query
@tanstack/react-query
add version to api/package.json to prevent yarn error
updated lock. Added prisma type to db/index to prevent prisma?
default to sqlite
update TS
Merge pull request #14 from ebg1223/updates
Updates
remove .idea
update clerk api key due to their new api key format
added .yarn nad .yarnrc.yml so user don't have to set yarn version or link-node
Update README.md
gitignore jetbrains
Update dependency: solito@2.1.3
solito
Merge pull request #15 from chen-rn/solito-2.1.3
Update dependency: solito@2.1.3
Update README.md
Update README.md
Update README.md
Update README.md
Update README.md
Update README.md
Update dependency: typescript@4.9.4
typescript
Update 5 dependencies
@trpc/next
@trpc/client
@trpc/server
@trpc/react-query
@tanstack/react-query
add version to api/package.json to prevent yarn error
updated lock. Added prisma type to db/index to prevent prisma?
default to sqlite
update TS
Merge pull request #14 from ebg1223/updates
Updates
remove .idea
update clerk api key due to their new api key format
added .yarn nad .yarnrc.yml so user don't have to set yarn version or link-node
Update README.md
gitignore jetbrains
Update dependency: solito@2.1.3
solito
Merge pull request #15 from chen-rn/solito-2.1.3
Update dependency: solito@2.1.3
There's a lot going on and I tried to reproduce in a forked repo, but the bug only manifests in my deployed app when changing routes twice. But given how I resolved it, I believe the bug originates from tamagui (or my understanding of how styled components work is incorrect).
Another relevant fact is that the bug only exists in the production build and only affects the web version. It affects all browsers that I tested (Safari, Chrome, Firefox).
Happy to give more details, but in its simplest form, I had a component that looks like:
const TOP_NAV_HEIGHT = 100;
const TopNav = styled(XStack, {
position: 'absolute',
top: 0,
left: 0,
right: 0,
bc: 'black',
height: TOP_NAV_HEIGHT,
alignItems: 'flex-end',
justifyContent: 'flex-end',
display: 'flex',
paddingBottom: 10,
px: 20,
animation: 'lazy',
zIndex: 300_000,
});
Which I render it in the following context:
return (
<YStack>
<TopNav
key={`top-nav`}
opacity={isScrollingDown ? 1 : 0}
y={isScrollingDown ? 0 : -TOP_NAV_HEIGHT}
>
<H2>SomeText</H2>
</TopNav>
<ScrollView
space={'$4'}
scrollEventThrottle={100}
paddingTop={TOP_NAV_HEIGHT}
onScroll={(e) => {
//Determine if scrolling down to trigger display/hiding of top nav
}}
>
//Arbitrary Content
</ScrollView>
<XGroup>
//Links to various pages with the same layout that differ only in the content displayed inside the ScrollView
</XGroup>
</YStack>
);
The problem is that when I navigate to on one of the links inside the XGroup twice, the TopNav
element loses most, but not all, of its properties (most importantly the absolute positioning). This causes a layout shift now that it occupies space on the page.
The reason I figure this is related to tamagui is because the fix is to replace TopNav
with an XStack
and inlining all of the properties that were passed into the styled
version:
return (
<YStack>
<XStack
key={`${pageTitle}-top-nav`}
opacity={isScrollingDown ? 1 : 0}
y={isScrollingDown ? 0 : -TOP_NAV_HEIGHT}
position={'absolute'}
top={0}
left={0}
right={0}
bc={'black'}
height={TOP_NAV_HEIGHT}
alignItems={'flex-end'}
justifyContent={'flex-end'}
display={'flex'}
paddingBottom={10}
px={20}
animation={'lazy'}
zIndex={300_000}
>
<H2>SomeText</H2>
</XStack>
<ScrollView
space={'$4'}
scrollEventThrottle={100}
paddingTop={TOP_NAV_HEIGHT}
onScroll={(e) => {
//Determine if scrolling down to trigger display/hiding of top nav
}}
>
//Arbitrary Content
</ScrollView>
<XGroup>
//Links to various pages with the same layout that differ only in the content displayed inside the ScrollView
</XGroup>
</YStack>
);
The above works fine in all environments and compilation targets, though from what I think I understand, it should be exactly the same as the styled
TopNav component (just built in a less reusable way).
@natew Strangely enough, I can't reproduce anymore (even after checking out the exact commits in which I observed this behavior). I wonder if I had old dependencies that I just needed to yarn install
? Anyway, apologies for the false report.
There's a lot going on and I tried to reproduce in a forked repo, but the bug only manifests in my deployed app when changing routes twice. But given how I resolved it, I believe the bug originates from tamagui (or my understanding of how styled components work is incorrect).
Another relevant fact is that the bug only exists in the production build and only affects the web version. It affects all browsers that I tested (Safari, Chrome, Firefox).
Happy to give more details, but in its simplest form, I had a component that looks like:
const TOP_NAV_HEIGHT = 100;
const TopNav = styled(XStack, {
position: 'absolute',
top: 0,
left: 0,
right: 0,
bc: 'black',
height: TOP_NAV_HEIGHT,
alignItems: 'flex-end',
justifyContent: 'flex-end',
display: 'flex',
paddingBottom: 10,
px: 20,
animation: 'lazy',
zIndex: 300_000,
});
Which I render it in the following context:
return (
<YStack>
<TopNav
key={`top-nav`}
opacity={isScrollingDown ? 1 : 0}
y={isScrollingDown ? 0 : -TOP_NAV_HEIGHT}
>
<H2>SomeText</H2>
</TopNav>
<ScrollView
space={'$4'}
scrollEventThrottle={100}
paddingTop={TOP_NAV_HEIGHT}
onScroll={(e) => {
//Determine if scrolling down to trigger display/hiding of top nav
}}
>
//Arbitrary Content
</ScrollView>
<XGroup>
//Links to various pages with the same layout that differ only in the content displayed inside the ScrollView
</XGroup>
</YStack>
);
The problem is that when I navigate to on one of the links inside the XGroup twice, the TopNav
element loses most, but not all, of its properties (most importantly the absolute positioning). This causes a layout shift now that it occupies space on the page.
The reason I figure this is related to tamagui is because the fix is to replace TopNav
with an XStack
and inlining all of the properties that were passed into the styled
version:
return (
<YStack>
<XStack
key={`${pageTitle}-top-nav`}
opacity={isScrollingDown ? 1 : 0}
y={isScrollingDown ? 0 : -TOP_NAV_HEIGHT}
position={'absolute'}
top={0}
left={0}
right={0}
bc={'black'}
height={TOP_NAV_HEIGHT}
alignItems={'flex-end'}
justifyContent={'flex-end'}
display={'flex'}
paddingBottom={10}
px={20}
animation={'lazy'}
zIndex={300_000}
>
<H2>SomeText</H2>
</XStack>
<ScrollView
space={'$4'}
scrollEventThrottle={100}
paddingTop={TOP_NAV_HEIGHT}
onScroll={(e) => {
//Determine if scrolling down to trigger display/hiding of top nav
}}
>
//Arbitrary Content
</ScrollView>
<XGroup>
//Links to various pages with the same layout that differ only in the content displayed inside the ScrollView
</XGroup>
</YStack>
);
The above works fine in all environments and compilation targets, though from what I think I understand, it should be exactly the same as the styled
TopNav component (just built in a less reusable way).
Update README.md
fixed expo build error, caused by conflict of namespace between /apps/next and /node_modules/next, changed our app to nextjs
quick patch, forgot to change the dev route, also upgrade tamagui
Update README.md
Update README.md
Required auth for accounts
Trigger re-deploy second attempt
Trigger re-deployment to update env variable
Include yarn.lock
First commit