{ "componentChunkName": "component---src-templates-blog-post-jsx", "path": "/pt-br/blog/coding/site-ou-app-sim-o-guia-gambiarrístico-para-sites-feitos-em-expo-router/", "result": {"data":{"site":{"siteMetadata":{"siteUrl":"https://pablo.gg"}},"markdownRemark":{"id":"e4f83ec8-3a67-5b7a-8ad3-eae98b17d4f7","excerpt":"Uma das side quests mais chatas de publicar um app na Google Play Store é que o Google às vezes decide que você também virou dono de site. Lá em 2024, quando eu…","html":"

Uma das side quests mais chatas de publicar um app na Google Play Store é que o Google às vezes decide que você também virou dono de site.

\n

Lá em 2024, quando eu escrevi pela primeira vez sobre o Musclog, o site existia basicamente porque o Google queria que ele existisse. Eu precisava da política de privacidade, das páginas públicas, do kit básico do desenvolvedor de app respeitável, então subi rapidinho um site pequeno em Next.js, consegui aprovar o app, e segui com a minha vida.

\n

Funcionou perfeitamente até o dia em que eu precisei mexer no site de novo.

\n

Screenshots novas? Outro repo. Texto de feature nova? Outro repo. Atualização de página legal? Outro repo. Ajustezinho de tradução? Outro repo.

\n

Nada disso era difícil de verdade, o que quase piorava a situação. Era só chato o suficiente pra continuar me lembrando que eu tinha dividido um produto em duas bases de código por um motivo que eu já não respeitava mais.

\n

Então agora eu não faço mais isso.

\n

O site do Musclog mora dentro do repo do app. Mesmo projeto com Expo Router. Mesmo deploy. musclog.app é o site público, musclog.app/app é o app web de verdade, e Android + iOS continuam saindo da mesma base de código.

\n

Boa prática? Questionável. Conveniente? Demais.

\n

\n \n ;\r\nimport { useEffect } from 'react';\r\nimport { Platform } from 'react-native';\r\n\r\nexport default function Index() {\r\n const router = useRouter();\r\n\r\n useEffect(() => {\r\n if (Platform.OS === 'web') {\r\n router.replace('/home');\r\n }\r\n }, [router]);\r\n\r\n if (Platform.OS === 'web') {\r\n return null;\r\n }\r\n\r\n return <Redirect href=\"/app\" />;\r\n}\n

É isso. No web, / vira o site. No native, / vira o app.

\n

O site também ganha o próprio layout mais leve:

\n
// app/(website)/_layout.web.tsx\r\nimport { Slot } from 'expo-router';\r\n\r\nimport { WebsiteChrome } from '@/components/website/WebsiteChrome';\r\nimport { WebsiteProviders } from '@/components/website/WebsiteProviders';\r\n\r\nexport default function WebsiteLayout() {\r\n  return (\r\n    <WebsiteProviders>\r\n      <WebsiteChrome>\r\n        <Slot />\r\n      </WebsiteChrome>\r\n    </WebsiteProviders>\r\n  );\r\n}
\n

Isso importa porque o layout do app de verdade já tinha crescido e virado um layout de app mesmo. Boot de banco, migrações, React Query, safe area, gestos, modais, snackbars, câmera, contexto do coach, todas aquelas mentiras clássicas de “é só um projetinho paralelo”. O site não precisa de nada disso só pra explicar o que o app faz.

\n

E se algum usuário nativo cair numa rota exclusiva do site, a correção é maravilhosamente direta:

\n
// app/(website)/home.tsx\r\nimport { Redirect } from 'expo-router';\r\n\r\nexport default function Home() {\r\n  return <Redirect href=\"/app\" />;\r\n}
\n

Pronto. Volta pros macros.

\n

\n \n \n \n \n
Site público do Musclog renderizado pela mesma base de código com Expo Router do app
\n

\n

A palhaçada do celular no desktop

\n

Foi aqui que eu parei de me comportar como uma pessoa normal.

\n

Eu queria que musclog.app/app, no desktop, mostrasse o app funcionando dentro de uma moldura de celular. Um pouco porque fica bonito. Um pouco porque funciona como preview do produto. Mas principalmente porque, depois que a ideia entrou na minha cabeça, qualquer opção menos ridícula começou a parecer errada.

\n

O detalhe chato era que /app precisava parecer um celular, mas /home definitivamente não. Então só o roteamento não bastava. Eu precisava que o shell bruto de HTML soubesse, antes da hidratação, se o navegador deveria renderizar a gambiarra do celular fake ou não.

\n

Essa lógica mora em app/+html.tsx, dentro de um script no <head> do documento:

\n
function landingPanelGate(base: string) {\r\n  try {\r\n    function update() {\r\n      const raw = window.location.pathname;\r\n      const path = (base && raw.startsWith(base) ? raw.slice(base.length) : raw) || '/';\r\n\r\n      if (!path.startsWith('/app')) {\r\n        document.documentElement.classList.add('hide-desktop-wrapper');\r\n      } else {\r\n        document.documentElement.classList.remove('hide-desktop-wrapper');\r\n      }\r\n    }\r\n\r\n    update();\r\n    window.addEventListener('popstate', update);\r\n\r\n    const origPush = history.pushState.bind(history);\r\n    history.pushState = function (...args) {\r\n      origPush(...args);\r\n      update();\r\n    };\r\n\r\n    const origReplace = history.replaceState.bind(history);\r\n    history.replaceState = function (...args) {\r\n      origReplace(...args);\r\n      update();\r\n    };\r\n  } catch (_) {}\r\n}
\n

A parte importante é a gambiarra em pushState / replaceState. A primeira renderização foi tranquila. A navegação client-side é que era a parte chata. Sem isso, dava pra sair de /app e continuar com o shell errado ali, como se o Chrome tivesse esquecido em que página estava.

\n

O shell HTML em si é basicamente o painel da landing, o app roteado, e a moldura do celular:

\n
<body className=\"expo-web-body\">\r\n  <div className=\"expo-web-landing\">...</div>\r\n  <script dangerouslySetInnerHTML={{ __html: LANDING_I18N_SCRIPT }} />\r\n  <div className=\"expo-web-root\">\r\n    <div className=\"expo-web-app-shell\">{children}</div>\r\n    <img\r\n      className=\"expo-web-phone-frame\"\r\n      src={withExpoBaseUrl(PHONE_FRAME_SRC)}\r\n      alt=\"\"\r\n      aria-hidden\r\n    />\r\n  </div>\r\n</body>
\n

Aí o CSS comete o crime:

\n
@media (min-width: 1024px) {\r\n  .expo-web-root {\r\n    --frame-h: min(100dvh, max(min(360px, 100dvh), 85dvh));\r\n    aspect-ratio: 1438 / 2976;\r\n    width: min(100vw, calc(var(--frame-h) * 1438 / 2976));\r\n    max-height: var(--frame-h);\r\n    overflow: hidden;\r\n  }\r\n\r\n  .expo-web-app-shell {\r\n    position: absolute;\r\n    left: 7.4409%;\r\n    top: 2.9906%;\r\n    right: 6.3282%;\r\n    bottom: 3.125%;\r\n    zoom: 0.85;\r\n  }\r\n}
\n

Sim, eu medi a área transparente da tela dentro do PNG até o app encaixar direito. Não tem geometria elegante nenhuma por trás dessas porcentagens. Era só eu, uma moldura de celular, e muito empurra-pra-lá até o app parar de parecer torto.

\n

Nas rotas que não são /app, o espetáculo inteiro é desligado:

\n
.hide-desktop-wrapper .expo-web-landing,\r\n.hide-desktop-wrapper .expo-web-phone-frame {\r\n  display: none !important;\r\n}\r\n\r\n.hide-desktop-wrapper .expo-web-app-shell {\r\n  position: static !important;\r\n  width: 100% !important;\r\n  height: auto !important;\r\n  zoom: 1 !important;\r\n  overflow: visible !important;\r\n}
\n

Sim, usa !important. Isso é CSS de pré-hidratação cujo trabalho inteiro é manter a mentira de pé. Não estamos fazendo arquitetura refinada nessa camada.

\n

\n \n \n \n \n
App web do Musclog no desktop renderizado dentro de uma moldura de celular ao lado da landing
\n

\n

Três pequenos crimes

\n

\"Direto

\n

Depois que o shell funcionou, os incômodos menores começaram a aparecer como se tivessem marcado horário.

\n

1. O painel da landing precisava de i18n antes da hidratação

\n

O texto do lado do celular mora em HTML cru, o que significa que React e i18n ainda estão dormindo quando a página renderiza pela primeira vez. Então, se eu quisesse que a página em português não desse um flash de inglês antes, eu tinha que remendar isso manualmente a partir do localStorage:

\n
function landingI18nPatcher(translations, storageKey) {\r\n  try {\r\n    let lang = localStorage.getItem(storageKey);\r\n    let s = (lang && translations[lang]) || translations['en-US'];\r\n\r\n    document.querySelectorAll('[data-landing-i18n]').forEach(function (el) {\r\n      let k = el.getAttribute('data-landing-i18n');\r\n      if (k && s[k]) {\r\n        el.textContent = s[k];\r\n      }\r\n    });\r\n  } catch (_) {}\r\n}
\n

Não é elegante. Também evita jogar um flashbang de texto em inglês numa página em português, então eu vou manter.

\n

2. Assets em HTML cru não recebem a ajuda de sempre do Expo

\n

O PNG da moldura do celular e o QR code também são referenciados a partir de HTML cru, então aquela conveniência normal de assets do Expo não me ajudava muito ali. Resultado: eu precisei de um helper pra base URL:

\n
function withExpoBaseUrl(path: string): string {\r\n  const base = process.env.EXPO_BASE_URL;\r\n  if (base == null || base === '') {\r\n    return path;\r\n  }\r\n\r\n  const basePath = String(base).replace(/^\\/+|\\/+$/g, '');\r\n  const normalized = path.startsWith('/') ? path : `/${path}`;\r\n  return `/${basePath}${normalized}`;\r\n}
\n

E como esses arquivos vivem fora do pipeline normal de assets do React Native, eu copio tudo pra public/ antes de rodar dev e export. Esquece esse passo uma vez e o site imediatamente te lembra quem manda.

\n

3. O expo export às vezes precisava de apoio emocional

\n

Em alguns ambientes, expo export --platform web terminava com sucesso e depois só… continuava vivo sem motivo nenhum. Pasta dist lá. Arquivos gerados. Processo espiritualmente concluído, tecnicamente ainda pendurado.

\n

Então agora existe um script wrapper:

\n
// scripts/export-web-wrapper.js\r\nif (output.includes('Exported: dist')) {\r\n  console.log('[export-web-wrapper] Detected successful export. Forcing exit in 5s...');\r\n  setTimeout(() => process.exit(0), 5000);\r\n}
\n

Não é glamouroso… mas resolve.

\n

Aí os modais ficaram esquisitos

\n

\n \n \n \n \n
Modal do Musclog no desktop renderizado corretamente dentro da moldura do celular
\n

\n

Claro que ficaram.

\n

Quando o app web mora dentro de um celular fake no desktop, o comportamento padrão de Modal no React Native Web começa a ficar ridículo bem rápido. Fazer portal direto pro document.body funciona bem quando o app é dono da página inteira. Funciona bem menos quando o app está visualmente recortado dentro de uma carcaça de celular e o modal decide do nada que agora pertence à janela inteira do navegador.

\n

Então eu adicionei um WebModalShellProvider lá em cima em app/app/_layout.tsx, com um host de overlay dentro do shell do celular:

\n
// context/WebModalShellContext.web.tsx\r\nreturn (\r\n  <WebModalShellContext.Provider value={{ hostElement }}>\r\n    <View style={{ flex: 1, minHeight: 0, height: '100%', width: '100%', position: 'relative' }}>\r\n      <View style={{ flex: 1, minHeight: 0, height: '100%', width: '100%' }} collapsable={false}>\r\n        {children}\r\n      </View>\r\n      <View\r\n        id=\"expo-web-modal-shell-host\"\r\n        ref={setHostRef}\r\n        collapsable={false}\r\n        style={{\r\n          position: 'absolute',\r\n          left: 0,\r\n          right: 0,\r\n          top: 0,\r\n          bottom: 0,\r\n          zIndex: 1_000_000,\r\n        }}\r\n      />\r\n    </View>\r\n  </WebModalShellContext.Provider>\r\n);
\n

Aí o Modal.web.tsx faz aquela coisa óbvia que só parece óbvia depois, alternando entre um portal dentro desse host e o modal normal do RN:

\n
const useShellPortal = Platform.OS === 'web' && isDesktopFrame && hostElement != null;\r\n\r\nif (useShellPortal) {\r\n  return createPortal(\r\n    <View\r\n      style={{\r\n        position: 'absolute',\r\n        left: 0,\r\n        right: 0,\r\n        top: 0,\r\n        bottom: 0,\r\n        width: '100%',\r\n        height: '100%',\r\n      }}\r\n    >\r\n      {children}\r\n    </View>,\r\n    hostElement\r\n  );\r\n}\r\n\r\nreturn <RNModal visible={visible}>{children}</RNModal>;
\n

E o hook compartilhado do overlay sabe se ele deve se comportar como um modal de viewport inteira ou como um modal de viewport de celular fake:

\n
export function useWebModalLayerStyle(options = {}) {\r\n  const isDesktopFrame = useWebDesktopPhoneFrame();\r\n\r\n  if (isDesktopFrame) {\r\n    return {\r\n      position: 'absolute',\r\n      top: 0,\r\n      left: 0,\r\n      right: 0,\r\n      bottom: 0,\r\n      width: '100%',\r\n      height: '100%',\r\n    };\r\n  }\r\n\r\n  return {\r\n    position: 'fixed',\r\n    top: 0,\r\n    left: 0,\r\n    right: 0,\r\n    bottom: 0,\r\n    width: '100vw',\r\n    height: '100dvh',\r\n  };\r\n}
\n

Isso resolveu a parte visual. Aí os pointer events decidiram que também queriam atenção.

\n

No native, pointerEvents=\"box-none\" é normal. No HTML, isso vira pointer-events: box-none, que não é CSS de verdade, então o navegador fica livre pra improvisar. Então agora existe uma regra defensiva pro host do overlay:

\n
.expo-web-app-shell #expo-web-modal-shell-host {\r\n  pointer-events: none !important;\r\n}\r\n\r\n.expo-web-app-shell #expo-web-modal-shell-host * {\r\n  pointer-events: auto !important;\r\n}
\n

Também existe um useLayoutEffect forçando a mesma coisa inline, porque a essa altura eu já não tinha mais interesse em descobrir quão elegante seria a solução correta.

\n

Eu claramente tenho um padrão

\n

Se você já lê este blog há algum tempo, nada disso deveria te surpreender.

\n

Eu já transformei este blog num RPG top-down porque o Konami Code merecia uma recompensa maior do que só um efeitinho de fundo.

\n

Depois eu coloquei Stories no blog porque o app da minha operadora tinha Stories, e isso me irritou profundamente num nível suficiente pra eu transformar o problema em problema de todo mundo.

\n

Então sim, é claro que agora o meu app de fitness serve o site a partir do mesmo repo com Expo Router, e é claro que o app web no desktop roda dentro de uma foto gigante de um celular. Isso não é uma escalada surpreendente. É só continuidade.

\n

Por que eu vou manter isso

\n

Passando da piada, isso resolveu um imposto de manutenção bem real.

\n

As traduções são compartilhadas. Os design tokens são compartilhados. Os componentes são compartilhados. As páginas legais ficam do lado do produto que elas estão legalmente defendendo. Quando eu mudo texto, screenshot ou posicionamento de feature, eu não preciso lembrar qual repo guarda a versão pública e comportada do mesmo app.

\n

O deploy também ficou melhor. Um build. Um export. Um artefato. O site e o app web não têm como sair de sincronia a não ser que eu faça questão de separá-los, o que fica bem mais difícil quando eles literalmente são publicados juntos.

\n

E quando eu lancei o redesign do Musclog, o site basicamente veio junto no embalo. Mesmo spacing, mesmas cores, screenshots atualizadas, mesmo PR. Exatamente o tipo de vitória chata de manutenção que faz uma decisão de arquitetura meio estranha parecer inteligente seis meses depois.

\n

Conclusão

\n

Eu poderia ter mantido o site num repo separado em Next.js como uma pessoa emocionalmente mais estável? Poderia.

\n

Eu ia continuar fazendo isso depois que o Expo Router deixou esse caminho aberto? Não.

\n

A parte engraçada é que o roteamento foi a parte sem graça. O Expo Router resolveu isso muito bem. O trabalho irritante estava em todas as mentirinhas de navegador ao redor: bloqueio de rota antes da hidratação, i18n em HTML cru, sincronização de assets, modais que sabiam em que shell estavam, esquisitice com pointer-events, e convencer o Chrome do desktop a acreditar temporariamente que era um celular.

\n

Ainda assim, valeu muito a pena.

\n

Se quiser fuçar o código, o Musclog é open-source no GitHub. Se quiser usar, tá em musclog.app. O site mora dentro do repo do app agora.

\n

Agora mora todo mundo aqui.

","fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDI2LTA0LTI1VDAwOjAwOjAwLjAwMFo=","slug":"/2026/2026-04-25-site-ou-app-sim-o-guia-gambiarrístico-para-sites-feitos-em-expo-router.pt-br/","path":"/blog/coding/site-ou-app-sim-o-guia-gambiarrístico-para-sites-feitos-em-expo-router/","locale":"pt-br"},"readingTime":{"minutes":11.475},"frontmatter":{"path":"site-ou-app-sim-o-guia-gambiarrístico-para-sites-feitos-em-expo-router","allowComments":true,"title":"Site ou App? Sim. O guia gambiarrístico para sites feitos em Expo Router","date":"2026-04-25T00:00:00.000Z","categories":["coding"],"tags":["expo","expo router","react native","musclog","website","monorepo","javascript","typescript"],"hideExcerpt":false,"subtitle":"O roteamento foi fácil. O celular fake no navegador foi a parte amaldiçoada."}},"categoryImage":{"childImageSharp":{"original":{"width":1920,"height":1080,"src":"/static/categories_coding-aa17d098a6a0d8e0a764a345865f5ffb.jpg"}}}},"pageContext":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDI2LTA0LTI1VDAwOjAwOjAwLjAwMFo=","relatedPosts":[{"fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDI2LTAzLTIyVDAwOjAwOjAwLjAwMFo=","slug":"/2026/2026-03-22-musclog-redesign-acompanhamento-nutricional-e-por-que-a-assinatura-do-seu-app-de-fitness-e-uma-enganacao.pt-br/","path":"/blog/coding/musclog-redesign-acompanhamento-nutricional-e-por-que-a-assinatura-do-seu-app-de-fitness-e-uma-enganacao/","locale":"pt-br"},"frontmatter":{"tags":["react","react native","expo","android","fitness","musclog","nutrition","usda","open food facts","stitch","design","offline","watermelondb","nativewind"],"categories":["coding"],"allowComments":true,"publishOnMedium":false,"cover":null,"date":"2026-03-22T00:00:00.000Z","id":null,"path":"musclog-redesign-acompanhamento-nutricional-e-por-que-a-assinatura-do-seu-app-de-fitness-e-uma-enganacao","show":true,"title":"Musclog: Redesign do acompanhamento nutricional e por que a assinatura do seu app de fitness é uma enganação","hideExcerpt":false,"subtitle":"Nova interface, bancos de dados de alimentos reais e um desabafo sobre assinaturas de apps de fitness que estou guardando há dois anos"}},{"fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDI0LTA5LTIxVDAwOjAwOjAwLjAwMFo=","slug":"/2024/2024-09-21-musclog-aproveitando-minha-experiencia-com-reactjs-para-criar-um-app-em-react-native.pt-br/","path":"/blog/coding/musclog-aproveitando-minha-experiencia-com-reactjs-para-criar-um-app-em-react-native/","locale":"pt-br"},"frontmatter":{"tags":["react","react native","expo","android","workout","tracker","logger","musclog"],"categories":["coding"],"allowComments":true,"publishOnMedium":false,"cover":null,"date":"2024-09-21T00:00:00.000Z","id":null,"path":"musclog-aproveitando-minha-experiencia-com-reactjs-para-criar-um-app-em-react-native","show":true,"title":"Musclog: Aproveitando minha experiência com React.js para criar um App em React Native","hideExcerpt":false,"subtitle":"De Bodybuilding para Codebuilding: Criando um aplicativo de fitness completo usando React Native e Expo"}},{"fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDI2LTAyLTEyVDAwOjAwOjAwLjAwMFo=","slug":"/2026/2026-02-12-por-que-a-regra-das-7700-calorias-e-falha-e-como-eu-a-corrigi-no-meu-app.pt-br/","path":"/blog/coding/por-que-a-regra-das-7700-calorias-e-falha-e-como-eu-a-corrigi-no-meu-app/","locale":"pt-br"},"frontmatter":{"tags":["typescript","musclog","algorithms","fitness","nutrition","bodybuilding"],"categories":["coding"],"allowComments":true,"publishOnMedium":true,"cover":null,"date":"2026-02-12T00:00:00.000Z","id":null,"path":"por-que-a-regra-das-7700-calorias-e-falha-e-como-eu-a-corrigi-no-meu-app","show":true,"title":"Por que a regra das 7700 calorias é falha (e como eu a corrigi no meu app)","hideExcerpt":false,"subtitle":"Spoiler: seu corpo não leu o manual"}},{"fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDI0LTEwLTI1VDAwOjAwOjAwLjAwMFo=","slug":"/2024/2024-10-25-compartilhando-cookies-encriptados-do-laravel-com-next-js.pt-br/","path":"/blog/coding/compartilhando-cookies-encriptados-do-laravel-com-next-js/","locale":"pt-br"},"frontmatter":{"tags":["laravel","next.js","cookies","encriptação","sincronização","desenvolvimento web","php","javascript"],"categories":["coding"],"allowComments":true,"publishOnMedium":false,"cover":null,"date":"2024-10-25T00:00:00.000Z","id":null,"path":"compartilhando-cookies-encriptados-do-laravel-com-next-js","show":true,"title":"Compartilhando cookies encriptados do Laravel com Next.js","hideExcerpt":false,"subtitle":"Conectando Laravel e Next.js: Como sincronizamos cookies encriptados entre dois frameworks diferentes."}},{"fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDI0LTA2LTE2VDAwOjAwOjAwLjAwMFo=","slug":"/2024/2024-06-16-calculando-minhas-horas-de-trabalho-em-projetos-pessoais-usando-nodejs.pt-br/","path":"/blog/coding/calculando-minhas-horas-de-trabalho-em-projetos-pessoais-usando-nodejs/","locale":"pt-br"},"frontmatter":{"tags":["nodejs","git","foss","javascript","simple-git","math"],"categories":["coding"],"allowComments":true,"publishOnMedium":false,"cover":null,"date":"2024-06-16T00:00:00.000Z","id":null,"path":"calculando-minhas-horas-de-trabalho-em-projetos-pessoais-usando-nodejs","show":true,"title":"Calculando minhas horas de trabalho em projetos pessoais usando Node.js","hideExcerpt":false,"subtitle":"Descobrindo da pior maneira que algumas informações não deveriam ser conhecidas"}},{"fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDIzLTEyLTIwVDAwOjAwOjAwLjAwMFo=","slug":"/2023/2023-12-20-como-automatizar-a-criacao-de-instagram-reels-usando-gpt-da-openai.pt-br/","path":"/blog/coding/como-automatizar-a-criacao-de-instagram-reels-usando-gpt-da-openai/","locale":"pt-br"},"frontmatter":{"tags":["openai","gpt","javascript","node","nodejs","instagram"],"categories":["coding"],"allowComments":true,"publishOnMedium":false,"cover":null,"date":"2023-12-20T00:00:00.000Z","id":null,"path":"como-automatizar-a-criacao-de-instagram-reels-usando-gpt-da-openai","show":true,"title":"Como automatizar a criação de Instagram Reels usando GPT da OpenAI","hideExcerpt":false,"subtitle":"Vídeos tutoriais automatizados com GPT-3.5 e Node.js."}},{"fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDIzLTEwLTI1VDAwOjAwOjAwLjAwMFo=","slug":"/2023/2023-10-25-como-criar-thumbnails-para-seus-videos-automaticamente-com-nodejs.pt-br/","path":"/blog/coding/como-criar-thumbnails-para-seus-videos-automaticamente-com-nodejs/","locale":"pt-br"},"frontmatter":{"tags":["instagram","miniatura","node","nodejs","javascript","canvas","imagem","vídeo"],"categories":["coding"],"allowComments":true,"publishOnMedium":false,"cover":null,"date":"2023-10-25T00:00:00.000Z","id":null,"path":"como-criar-thumbnails-para-seus-videos-automaticamente-com-nodejs","show":true,"title":"Como criar thumbnails para seus vídeos automaticamente com Node.js","hideExcerpt":false,"subtitle":"A melhor forma de criar thumbnails para seus vídeos no Instagram"}},{"fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDIzLTEwLTE0VDAwOjAwOjAwLjAwMFo=","slug":"/2023/2023-10-14-publicando-reels-no-instagram-usando-nodejs-e-a-arte-de-superar-limitacoes.pt-br/","path":"/blog/coding/publicando-reels-no-instagram-usando-nodejs-e-a-arte-de-superar-limitacoes/","locale":"pt-br"},"frontmatter":{"tags":["instagram","node","nodejs","javascript","axios","ngrok","ffmpeg","automação"],"categories":["coding"],"allowComments":true,"publishOnMedium":false,"cover":null,"date":"2023-10-14T00:00:00.000Z","id":null,"path":"publicando-reels-no-instagram-usando-nodejs-e-a-arte-de-superar-limitacoes","show":true,"title":"Publicando Reels no Instagram usando Node.js e a arte de superar limitações","hideExcerpt":false,"subtitle":"Afinal, por que gastar 30 segundos fazendo algo manualmente quando você pode gastar 30 horas automatizando-o?"}},{"fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDIzLTA5LTA0VDAwOjAwOjAwLjAwMFo=","slug":"/2023/2023-09-04-meu-blog-tem-stories-agora-mas-nao-me-pergunte-por-que.pt-br/","path":"/blog/coding/meu-blog-tem-stories-agora-mas-nao-me-pergunte-por-que/","locale":"pt-br"},"frontmatter":{"tags":["instagram","instagram stories","invenções desnecessárias","gatsby","react","javascript"],"categories":["coding"],"allowComments":true,"publishOnMedium":false,"cover":null,"date":"2023-09-04T00:00:00.000Z","id":null,"path":"meu-blog-tem-stories-agora-mas-nao-me-pergunte-por-que","show":true,"title":"Meu blog tem Stories agora, mas não me pergunte por quê","hideExcerpt":false,"subtitle":"Quem disse que tédio não é produtivo?"}},{"fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDIzLTA4LTAyVDAwOjAwOjAwLjAwMFo=","slug":"/2023/2023-08-02-usando-google-fitness-api-para-calcular-meu-tdee-e-mais.pt-br/","path":"/blog/coding/usando-google-fitness-api-para-calcular-meu-tdee-e-mais/","locale":"pt-br"},"frontmatter":{"tags":["google cloud","fitness api","google fit","nodejs","node","javascript"],"categories":["coding"],"allowComments":true,"publishOnMedium":false,"cover":null,"date":"2023-08-02T00:00:00.000Z","id":null,"path":"usando-google-fitness-api-para-calcular-meu-tdee-e-mais","show":true,"title":"Usando Google Fitness API para calcular meu TDEE e mais","hideExcerpt":false,"subtitle":"De calorias para código: Integrando Google Fitness API para insights personalizados de saúde"}}],"alternativeHtml":"

Uma das side quests mais chatas de publicar um app na Google Play Store é que o Google às vezes decide que você também virou dono de site.

\n

Lá em 2024, quando eu escrevi pela primeira vez sobre o Musclog, o site existia basicamente porque o Google queria que ele existisse. Eu precisava da política de privacidade, das páginas públicas, do kit básico do desenvolvedor de app respeitável, então subi rapidinho um site pequeno em Next.js, consegui aprovar o app, e segui com a minha vida.

\n

Funcionou perfeitamente até o dia em que eu precisei mexer no site de novo.

\n

Screenshots novas? Outro repo. Texto de feature nova? Outro repo. Atualização de página legal? Outro repo. Ajustezinho de tradução? Outro repo.

\n

Nada disso era difícil de verdade, o que quase piorava a situação. Era só chato o suficiente pra continuar me lembrando que eu tinha dividido um produto em duas bases de código por um motivo que eu já não respeitava mais.

\n

Então agora eu não faço mais isso.

\n

O site do Musclog mora dentro do repo do app. Mesmo projeto com Expo Router. Mesmo deploy. musclog.app é o site público, musclog.app/app é o app web de verdade, e Android + iOS continuam saindo da mesma base de código.

\n

Boa prática? Questionável. Conveniente? Demais.

\n

\n \n ;\nimport { useEffect } from 'react';\nimport { Platform } from 'react-native';\n\nexport default function Index() {\n const router = useRouter();\n\n useEffect(() => {\n if (Platform.OS === 'web') {\n router.replace('/home');\n }\n }, [router]);\n\n if (Platform.OS === 'web') {\n return null;\n }\n\n return <Redirect href=\"/app\" />;\n}\n

É isso. No web, / vira o site. No native, / vira o app.

\n

O site também ganha o próprio layout mais leve:

\n
// app/(website)/_layout.web.tsx\nimport { Slot } from 'expo-router';\n\nimport { WebsiteChrome } from '@/components/website/WebsiteChrome';\nimport { WebsiteProviders } from '@/components/website/WebsiteProviders';\n\nexport default function WebsiteLayout() {\n  return (\n    <WebsiteProviders>\n      <WebsiteChrome>\n        <Slot />\n      </WebsiteChrome>\n    </WebsiteProviders>\n  );\n}
\n

Isso importa porque o layout do app de verdade já tinha crescido e virado um layout de app mesmo. Boot de banco, migrações, React Query, safe area, gestos, modais, snackbars, câmera, contexto do coach, todas aquelas mentiras clássicas de “é só um projetinho paralelo”. O site não precisa de nada disso só pra explicar o que o app faz.

\n

E se algum usuário nativo cair numa rota exclusiva do site, a correção é maravilhosamente direta:

\n
// app/(website)/home.tsx\nimport { Redirect } from 'expo-router';\n\nexport default function Home() {\n  return <Redirect href=\"/app\" />;\n}
\n

Pronto. Volta pros macros.

\n

\n \n \n \"Site\n \n
Site público do Musclog renderizado pela mesma base de código com Expo Router do app
\n

\n

A palhaçada do celular no desktop

\n

Foi aqui que eu parei de me comportar como uma pessoa normal.

\n

Eu queria que musclog.app/app, no desktop, mostrasse o app funcionando dentro de uma moldura de celular. Um pouco porque fica bonito. Um pouco porque funciona como preview do produto. Mas principalmente porque, depois que a ideia entrou na minha cabeça, qualquer opção menos ridícula começou a parecer errada.

\n

O detalhe chato era que /app precisava parecer um celular, mas /home definitivamente não. Então só o roteamento não bastava. Eu precisava que o shell bruto de HTML soubesse, antes da hidratação, se o navegador deveria renderizar a gambiarra do celular fake ou não.

\n

Essa lógica mora em app/+html.tsx, dentro de um script no <head> do documento:

\n
function landingPanelGate(base: string) {\n  try {\n    function update() {\n      const raw = window.location.pathname;\n      const path = (base && raw.startsWith(base) ? raw.slice(base.length) : raw) || '/';\n\n      if (!path.startsWith('/app')) {\n        document.documentElement.classList.add('hide-desktop-wrapper');\n      } else {\n        document.documentElement.classList.remove('hide-desktop-wrapper');\n      }\n    }\n\n    update();\n    window.addEventListener('popstate', update);\n\n    const origPush = history.pushState.bind(history);\n    history.pushState = function (...args) {\n      origPush(...args);\n      update();\n    };\n\n    const origReplace = history.replaceState.bind(history);\n    history.replaceState = function (...args) {\n      origReplace(...args);\n      update();\n    };\n  } catch (_) {}\n}
\n

A parte importante é a gambiarra em pushState / replaceState. A primeira renderização foi tranquila. A navegação client-side é que era a parte chata. Sem isso, dava pra sair de /app e continuar com o shell errado ali, como se o Chrome tivesse esquecido em que página estava.

\n

O shell HTML em si é basicamente o painel da landing, o app roteado, e a moldura do celular:

\n
<body className=\"expo-web-body\">\n  <div className=\"expo-web-landing\">...</div>\n  <script dangerouslySetInnerHTML={{ __html: LANDING_I18N_SCRIPT }} />\n  <div className=\"expo-web-root\">\n    <div className=\"expo-web-app-shell\">{children}</div>\n    <img\n      className=\"expo-web-phone-frame\"\n      src={withExpoBaseUrl(PHONE_FRAME_SRC)}\n      alt=\"\"\n      aria-hidden\n    />\n  </div>\n</body>
\n

Aí o CSS comete o crime:

\n
@media (min-width: 1024px) {\n  .expo-web-root {\n    --frame-h: min(100dvh, max(min(360px, 100dvh), 85dvh));\n    aspect-ratio: 1438 / 2976;\n    width: min(100vw, calc(var(--frame-h) * 1438 / 2976));\n    max-height: var(--frame-h);\n    overflow: hidden;\n  }\n\n  .expo-web-app-shell {\n    position: absolute;\n    left: 7.4409%;\n    top: 2.9906%;\n    right: 6.3282%;\n    bottom: 3.125%;\n    zoom: 0.85;\n  }\n}
\n

Sim, eu medi a área transparente da tela dentro do PNG até o app encaixar direito. Não tem geometria elegante nenhuma por trás dessas porcentagens. Era só eu, uma moldura de celular, e muito empurra-pra-lá até o app parar de parecer torto.

\n

Nas rotas que não são /app, o espetáculo inteiro é desligado:

\n
.hide-desktop-wrapper .expo-web-landing,\n.hide-desktop-wrapper .expo-web-phone-frame {\n  display: none !important;\n}\n\n.hide-desktop-wrapper .expo-web-app-shell {\n  position: static !important;\n  width: 100% !important;\n  height: auto !important;\n  zoom: 1 !important;\n  overflow: visible !important;\n}
\n

Sim, usa !important. Isso é CSS de pré-hidratação cujo trabalho inteiro é manter a mentira de pé. Não estamos fazendo arquitetura refinada nessa camada.

\n

\n \n \n \"App\n \n
App web do Musclog no desktop renderizado dentro de uma moldura de celular ao lado da landing
\n

\n

Três pequenos crimes

\n

\"Direto

\n

Depois que o shell funcionou, os incômodos menores começaram a aparecer como se tivessem marcado horário.

\n

1. O painel da landing precisava de i18n antes da hidratação

\n

O texto do lado do celular mora em HTML cru, o que significa que React e i18n ainda estão dormindo quando a página renderiza pela primeira vez. Então, se eu quisesse que a página em português não desse um flash de inglês antes, eu tinha que remendar isso manualmente a partir do localStorage:

\n
function landingI18nPatcher(translations, storageKey) {\n  try {\n    let lang = localStorage.getItem(storageKey);\n    let s = (lang && translations[lang]) || translations['en-US'];\n\n    document.querySelectorAll('[data-landing-i18n]').forEach(function (el) {\n      let k = el.getAttribute('data-landing-i18n');\n      if (k && s[k]) {\n        el.textContent = s[k];\n      }\n    });\n  } catch (_) {}\n}
\n

Não é elegante. Também evita jogar um flashbang de texto em inglês numa página em português, então eu vou manter.

\n

2. Assets em HTML cru não recebem a ajuda de sempre do Expo

\n

O PNG da moldura do celular e o QR code também são referenciados a partir de HTML cru, então aquela conveniência normal de assets do Expo não me ajudava muito ali. Resultado: eu precisei de um helper pra base URL:

\n
function withExpoBaseUrl(path: string): string {\n  const base = process.env.EXPO_BASE_URL;\n  if (base == null || base === '') {\n    return path;\n  }\n\n  const basePath = String(base).replace(/^\\/+|\\/+$/g, '');\n  const normalized = path.startsWith('/') ? path : `/${path}`;\n  return `/${basePath}${normalized}`;\n}
\n

E como esses arquivos vivem fora do pipeline normal de assets do React Native, eu copio tudo pra public/ antes de rodar dev e export. Esquece esse passo uma vez e o site imediatamente te lembra quem manda.

\n

3. O expo export às vezes precisava de apoio emocional

\n

Em alguns ambientes, expo export --platform web terminava com sucesso e depois só… continuava vivo sem motivo nenhum. Pasta dist lá. Arquivos gerados. Processo espiritualmente concluído, tecnicamente ainda pendurado.

\n

Então agora existe um script wrapper:

\n
// scripts/export-web-wrapper.js\nif (output.includes('Exported: dist')) {\n  console.log('[export-web-wrapper] Detected successful export. Forcing exit in 5s...');\n  setTimeout(() => process.exit(0), 5000);\n}
\n

Não é glamouroso… mas resolve.

\n

Aí os modais ficaram esquisitos

\n

\n \n \n \"Modal\n \n
Modal do Musclog no desktop renderizado corretamente dentro da moldura do celular
\n

\n

Claro que ficaram.

\n

Quando o app web mora dentro de um celular fake no desktop, o comportamento padrão de Modal no React Native Web começa a ficar ridículo bem rápido. Fazer portal direto pro document.body funciona bem quando o app é dono da página inteira. Funciona bem menos quando o app está visualmente recortado dentro de uma carcaça de celular e o modal decide do nada que agora pertence à janela inteira do navegador.

\n

Então eu adicionei um WebModalShellProvider lá em cima em app/app/_layout.tsx, com um host de overlay dentro do shell do celular:

\n
// context/WebModalShellContext.web.tsx\nreturn (\n  <WebModalShellContext.Provider value={{ hostElement }}>\n    <View style={{ flex: 1, minHeight: 0, height: '100%', width: '100%', position: 'relative' }}>\n      <View style={{ flex: 1, minHeight: 0, height: '100%', width: '100%' }} collapsable={false}>\n        {children}\n      </View>\n      <View\n        id=\"expo-web-modal-shell-host\"\n        ref={setHostRef}\n        collapsable={false}\n        style={{\n          position: 'absolute',\n          left: 0,\n          right: 0,\n          top: 0,\n          bottom: 0,\n          zIndex: 1_000_000,\n        }}\n      />\n    </View>\n  </WebModalShellContext.Provider>\n);
\n

Aí o Modal.web.tsx faz aquela coisa óbvia que só parece óbvia depois, alternando entre um portal dentro desse host e o modal normal do RN:

\n
const useShellPortal = Platform.OS === 'web' && isDesktopFrame && hostElement != null;\n\nif (useShellPortal) {\n  return createPortal(\n    <View\n      style={{\n        position: 'absolute',\n        left: 0,\n        right: 0,\n        top: 0,\n        bottom: 0,\n        width: '100%',\n        height: '100%',\n      }}\n    >\n      {children}\n    </View>,\n    hostElement\n  );\n}\n\nreturn <RNModal visible={visible}>{children}</RNModal>;
\n

E o hook compartilhado do overlay sabe se ele deve se comportar como um modal de viewport inteira ou como um modal de viewport de celular fake:

\n
export function useWebModalLayerStyle(options = {}) {\n  const isDesktopFrame = useWebDesktopPhoneFrame();\n\n  if (isDesktopFrame) {\n    return {\n      position: 'absolute',\n      top: 0,\n      left: 0,\n      right: 0,\n      bottom: 0,\n      width: '100%',\n      height: '100%',\n    };\n  }\n\n  return {\n    position: 'fixed',\n    top: 0,\n    left: 0,\n    right: 0,\n    bottom: 0,\n    width: '100vw',\n    height: '100dvh',\n  };\n}
\n

Isso resolveu a parte visual. Aí os pointer events decidiram que também queriam atenção.

\n

No native, pointerEvents=\"box-none\" é normal. No HTML, isso vira pointer-events: box-none, que não é CSS de verdade, então o navegador fica livre pra improvisar. Então agora existe uma regra defensiva pro host do overlay:

\n
.expo-web-app-shell #expo-web-modal-shell-host {\n  pointer-events: none !important;\n}\n\n.expo-web-app-shell #expo-web-modal-shell-host * {\n  pointer-events: auto !important;\n}
\n

Também existe um useLayoutEffect forçando a mesma coisa inline, porque a essa altura eu já não tinha mais interesse em descobrir quão elegante seria a solução correta.

\n

Eu claramente tenho um padrão

\n

Se você já lê este blog há algum tempo, nada disso deveria te surpreender.

\n

Eu já transformei este blog num RPG top-down porque o Konami Code merecia uma recompensa maior do que só um efeitinho de fundo.

\n

Depois eu coloquei Stories no blog porque o app da minha operadora tinha Stories, e isso me irritou profundamente num nível suficiente pra eu transformar o problema em problema de todo mundo.

\n

Então sim, é claro que agora o meu app de fitness serve o site a partir do mesmo repo com Expo Router, e é claro que o app web no desktop roda dentro de uma foto gigante de um celular. Isso não é uma escalada surpreendente. É só continuidade.

\n

Por que eu vou manter isso

\n

Passando da piada, isso resolveu um imposto de manutenção bem real.

\n

As traduções são compartilhadas. Os design tokens são compartilhados. Os componentes são compartilhados. As páginas legais ficam do lado do produto que elas estão legalmente defendendo. Quando eu mudo texto, screenshot ou posicionamento de feature, eu não preciso lembrar qual repo guarda a versão pública e comportada do mesmo app.

\n

O deploy também ficou melhor. Um build. Um export. Um artefato. O site e o app web não têm como sair de sincronia a não ser que eu faça questão de separá-los, o que fica bem mais difícil quando eles literalmente são publicados juntos.

\n

E quando eu lancei o redesign do Musclog, o site basicamente veio junto no embalo. Mesmo spacing, mesmas cores, screenshots atualizadas, mesmo PR. Exatamente o tipo de vitória chata de manutenção que faz uma decisão de arquitetura meio estranha parecer inteligente seis meses depois.

\n

Conclusão

\n

Eu poderia ter mantido o site num repo separado em Next.js como uma pessoa emocionalmente mais estável? Poderia.

\n

Eu ia continuar fazendo isso depois que o Expo Router deixou esse caminho aberto? Não.

\n

A parte engraçada é que o roteamento foi a parte sem graça. O Expo Router resolveu isso muito bem. O trabalho irritante estava em todas as mentirinhas de navegador ao redor: bloqueio de rota antes da hidratação, i18n em HTML cru, sincronização de assets, modais que sabiam em que shell estavam, esquisitice com pointer-events, e convencer o Chrome do desktop a acreditar temporariamente que era um celular.

\n

Ainda assim, valeu muito a pena.

\n

Se quiser fuçar o código, o Musclog é open-source no GitHub. Se quiser usar, tá em musclog.app. O site mora dentro do repo do app agora.

\n

Agora mora todo mundo aqui.

","otherLanguagesUrl":["/en/blog/coding/website-or-app-yes-hacky-expo-router-guide/"],"rss":{"title":"Site ou App? Sim. O guia gambiarrístico para sites feitos em Expo Router","description":"Site ou App? Sim. O guia gambiarrístico para sites feitos em Expo Router","date":"2026-04-25T00:00:00.000Z"},"images":["/static/f71a459f3034e47544de2f3ce309dd61/42a19/musclog-shared-router-website-home-1.png","/static/c50b08ecc21b0e02ed7774578063a5f6/42a19/musclog-shared-router-website-home-2.png","/static/49361b3283ae34ef30a950b13c7f5594/42a19/musclog-desktop-phone-frame-wrapper.png","/377ac4354ce553fccf98c5d8d1017e50/straight-to-jail.gif","/static/a2af4c3fcf36eee559fddfb48a5143d1/42a19/musclog-desktop-modal-inside-phone-frame.png"],"videos":[],"comments":[],"googleFormData":{"fvv":1,"pageHistory":0,"fbzx":"2341154569390836157","action":"e/1FAIpQLSeST_0jBnLKkEkXGpyx9LWrvV2a1-1F5dr-AcA4wn0BSRyPCw","title":"blog_comment","description":null,"fields":[{"label":"name","description":null,"type":"SHORT_ANSWER","id":"1953327618","required":true},{"label":"email","description":null,"type":"SHORT_ANSWER","id":"1309141965","required":false},{"label":"twitter","description":null,"type":"SHORT_ANSWER","id":"740186305","required":false},{"label":"comment","description":null,"type":"LONG_ANSWER","id":"1663940054","required":true},{"label":"post_path","description":null,"type":"SHORT_ANSWER","id":"1852628638","required":true}],"fieldsOrder":{"740186305":2,"1309141965":1,"1663940054":3,"1852628638":4,"1953327618":0}},"pageType":"blogPost","categoryImage":"/categories_coding.jpg/","slug":"/2026/2026-04-25-site-ou-app-sim-o-guia-gambiarrístico-para-sites-feitos-em-expo-router.pt-br/","locale":"pt-br","title":"Site ou App? Sim. O guia gambiarrístico para sites feitos em Expo Router","previous":{"excerpt":"One of the annoying little side quests of shipping an app is…","html":"

One of the annoying little side quests of shipping an app is that Google occasionally forces you to become a website owner too.

\n

Back when I first wrote about Musclog in 2024, the website mostly existed because Google wanted it to exist. I needed the privacy policy, the public pages, the whole respectable app developer starter pack, so I quickly spun up a small Next.js site, got the app approved, and moved on with my life.

\n

That worked right until I had to touch the website again.

\n

New screenshots? Other repo. New feature copy? Other repo. Legal page update? Other repo. Translation tweak? Other repo.

\n

None of that was actually hard, which almost made it worse. It was just annoying enough to keep reminding me that I had split one product into two codebases for a reason I no longer respected.

\n

So now I don’t.

\n

Musclog’s website lives inside the app repo. Same Expo Router project. Same deploy. musclog.app is the public site, musclog.app/app is the actual web app, and Android + iOS still come from the same codebase.

\n

Best practice? Questionable. Convenient? Extremely.

\n

\n \n ;\r\nimport { useEffect } from 'react';\r\nimport { Platform } from 'react-native';\r\n\r\nexport default function Index() {\r\n const router = useRouter();\r\n\r\n useEffect(() => {\r\n if (Platform.OS === 'web') {\r\n router.replace('/home');\r\n }\r\n }, [router]);\r\n\r\n if (Platform.OS === 'web') {\r\n return null;\r\n }\r\n\r\n return <Redirect href=\"/app\" />;\r\n}\n

That’s it. On web, / becomes the website. On native, / becomes the app.

\n

The website also gets its own lighter layout:

\n
// app/(website)/_layout.web.tsx\r\nimport { Slot } from 'expo-router';\r\n\r\nimport { WebsiteChrome } from '@/components/website/WebsiteChrome';\r\nimport { WebsiteProviders } from '@/components/website/WebsiteProviders';\r\n\r\nexport default function WebsiteLayout() {\r\n  return (\r\n    <WebsiteProviders>\r\n      <WebsiteChrome>\r\n        <Slot />\r\n      </WebsiteChrome>\r\n    </WebsiteProviders>\r\n  );\r\n}
\n

That matters because the real app layout had already grown into an actual app layout. Database boot, migrations, React Query, safe area, gestures, modals, snackbars, camera, coach context, all the usual “small side project” lies. The website does not need any of that just to explain what the app does.

\n

And if a native user somehow lands on a website-only route, the fix is beautifully blunt:

\n
// app/(website)/home.tsx\r\nimport { Redirect } from 'expo-router';\r\n\r\nexport default function Home() {\r\n  return <Redirect href=\"/app\" />;\r\n}
\n

Done. Back to your macros.

\n

\n \n \n \n \n
Musclog public website rendered from the same Expo Router codebase as the app
\n

\n

The desktop phone nonsense

\n

This is where I stopped behaving like a normal person.

\n

I wanted musclog.app/app on desktop to show the actual working app inside a phone frame. Partly because it looks nice. Partly because it doubles as a product preview. Mostly because once the idea entered my head, every less ridiculous option started feeling wrong.

\n

The annoying detail was that /app should look like a phone, but /home absolutely should not. So routing alone was not enough. I needed the raw HTML shell to know, before hydration, whether the browser should render the fake phone wrapper or not.

\n

That logic lives in app/+html.tsx, inside a script in the document <head>:

\n
function landingPanelGate(base: string) {\r\n  try {\r\n    function update() {\r\n      const raw = window.location.pathname;\r\n      const path = (base && raw.startsWith(base) ? raw.slice(base.length) : raw) || '/';\r\n\r\n      if (!path.startsWith('/app')) {\r\n        document.documentElement.classList.add('hide-desktop-wrapper');\r\n      } else {\r\n        document.documentElement.classList.remove('hide-desktop-wrapper');\r\n      }\r\n    }\r\n\r\n    update();\r\n    window.addEventListener('popstate', update);\r\n\r\n    const origPush = history.pushState.bind(history);\r\n    history.pushState = function (...args) {\r\n      origPush(...args);\r\n      update();\r\n    };\r\n\r\n    const origReplace = history.replaceState.bind(history);\r\n    history.replaceState = function (...args) {\r\n      origReplace(...args);\r\n      update();\r\n    };\r\n  } catch (_) {}\r\n}
\n

The important part is the pushState / replaceState monkey patch. First paint was easy. Client-side navigation was the annoying bit. Without this, you could leave /app and keep the wrong shell around like Chrome had forgotten what page it was on.

\n

The HTML shell itself is basically the landing panel, the routed app, and the phone frame:

\n
<body className=\"expo-web-body\">\r\n  <div className=\"expo-web-landing\">...</div>\r\n  <script dangerouslySetInnerHTML={{ __html: LANDING_I18N_SCRIPT }} />\r\n  <div className=\"expo-web-root\">\r\n    <div className=\"expo-web-app-shell\">{children}</div>\r\n    <img\r\n      className=\"expo-web-phone-frame\"\r\n      src={withExpoBaseUrl(PHONE_FRAME_SRC)}\r\n      alt=\"\"\r\n      aria-hidden\r\n    />\r\n  </div>\r\n</body>
\n

Then CSS commits the crime:

\n
@media (min-width: 1024px) {\r\n  .expo-web-root {\r\n    --frame-h: min(100dvh, max(min(360px, 100dvh), 85dvh));\r\n    aspect-ratio: 1438 / 2976;\r\n    width: min(100vw, calc(var(--frame-h) * 1438 / 2976));\r\n    max-height: var(--frame-h);\r\n    overflow: hidden;\r\n  }\r\n\r\n  .expo-web-app-shell {\r\n    position: absolute;\r\n    left: 7.4409%;\r\n    top: 2.9906%;\r\n    right: 6.3282%;\r\n    bottom: 3.125%;\r\n    zoom: 0.85;\r\n  }\r\n}
\n

Yes, I measured the transparent screen area inside the PNG until the app lined up correctly. There is no elegant geometry behind those percentages. It was just me, a phone bezel, and a lot of nudging until the app stopped looking crooked.

\n

On routes that are not /app, the whole performance gets disabled:

\n
.hide-desktop-wrapper .expo-web-landing,\r\n.hide-desktop-wrapper .expo-web-phone-frame {\r\n  display: none !important;\r\n}\r\n\r\n.hide-desktop-wrapper .expo-web-app-shell {\r\n  position: static !important;\r\n  width: 100% !important;\r\n  height: auto !important;\r\n  zoom: 1 !important;\r\n  overflow: visible !important;\r\n}
\n

Yes, it uses !important. This is pre-hydration CSS whose entire job is keeping the lie intact. We are not doing refined architecture at this layer.

\n

\n \n \n \n \n
Musclog desktop web app rendered inside a phone frame next to the landing panel
\n

\n

Three tiny crimes

\n

\"Straight

\n

Once the shell worked, the smaller annoyances started lining up like they had booked appointments.

\n

1. The landing panel needed i18n before hydration

\n

The text beside the phone frame lives in raw HTML, which means React and i18n are still sleeping when the page first renders. So if I wanted a Portuguese page to not flash English first, I had to patch it myself from localStorage:

\n
function landingI18nPatcher(translations, storageKey) {\r\n  try {\r\n    let lang = localStorage.getItem(storageKey);\r\n    let s = (lang && translations[lang]) || translations['en-US'];\r\n\r\n    document.querySelectorAll('[data-landing-i18n]').forEach(function (el) {\r\n      let k = el.getAttribute('data-landing-i18n');\r\n      if (k && s[k]) {\r\n        el.textContent = s[k];\r\n      }\r\n    });\r\n  } catch (_) {}\r\n}
\n

Not elegant. Also not flash-banging a Portuguese page with English text, so I’m keeping it.

\n

2. Raw HTML assets do not get Expo’s usual help

\n

The phone frame PNG and QR code are referenced from raw HTML too, which means Expo’s usual asset niceness does not really help me there. So I needed a helper for base URLs:

\n
function withExpoBaseUrl(path: string): string {\r\n  const base = process.env.EXPO_BASE_URL;\r\n  if (base == null || base === '') {\r\n    return path;\r\n  }\r\n\r\n  const basePath = String(base).replace(/^\\/+|\\/+$/g, '');\r\n  const normalized = path.startsWith('/') ? path : `/${path}`;\r\n  return `/${basePath}${normalized}`;\r\n}
\n

And because those files live outside the React Native asset pipeline, I copy them into public/ before dev and export. Forget that step once and the site immediately reminds you who is in charge.

\n

3. expo export occasionally needed emotional support

\n

In some environments, expo export --platform web would successfully finish and then just stay alive for no reason. Dist folder there. Files generated. Process spiritually complete, technically still hanging around.

\n

So now there is a wrapper script:

\n
// scripts/export-web-wrapper.js\r\nif (output.includes('Exported: dist')) {\r\n  console.log('[export-web-wrapper] Detected successful export. Forcing exit in 5s...');\r\n  setTimeout(() => process.exit(0), 5000);\r\n}
\n

Not glamorous. Very effective.

\n

Then modals got weird

\n

\n \n \n \n \n
Musclog desktop modal rendered correctly inside the phone frame
\n

\n

Of course they did.

\n

When the web app lives inside a fake phone on desktop, React Native Web’s default Modal behavior starts looking ridiculous very quickly. Portaling straight to document.body is fine when the whole app owns the page. It is much less fine when the app is visually clipped inside a phone shell and the modal suddenly decides it belongs to the whole browser window instead.

\n

So I added a WebModalShellProvider high in app/app/_layout.tsx, with an overlay host inside the phone shell:

\n
// context/WebModalShellContext.web.tsx\r\nreturn (\r\n  <WebModalShellContext.Provider value={{ hostElement }}>\r\n    <View style={{ flex: 1, minHeight: 0, height: '100%', width: '100%', position: 'relative' }}>\r\n      <View style={{ flex: 1, minHeight: 0, height: '100%', width: '100%' }} collapsable={false}>\r\n        {children}\r\n      </View>\r\n      <View\r\n        id=\"expo-web-modal-shell-host\"\r\n        ref={setHostRef}\r\n        collapsable={false}\r\n        style={{\r\n          position: 'absolute',\r\n          left: 0,\r\n          right: 0,\r\n          top: 0,\r\n          bottom: 0,\r\n          zIndex: 1_000_000,\r\n        }}\r\n      />\r\n    </View>\r\n  </WebModalShellContext.Provider>\r\n);
\n

Then Modal.web.tsx does the obvious-not-obvious thing and switches between a portal inside that host and the normal RN modal:

\n
const useShellPortal = Platform.OS === 'web' && isDesktopFrame && hostElement != null;\r\n\r\nif (useShellPortal) {\r\n  return createPortal(\r\n    <View\r\n      style={{\r\n        position: 'absolute',\r\n        left: 0,\r\n        right: 0,\r\n        top: 0,\r\n        bottom: 0,\r\n        width: '100%',\r\n        height: '100%',\r\n      }}\r\n    >\r\n      {children}\r\n    </View>,\r\n    hostElement\r\n  );\r\n}\r\n\r\nreturn <RNModal visible={visible}>{children}</RNModal>;
\n

And the shared overlay hook knows whether it should behave like a full viewport modal or a fake-phone viewport modal:

\n
export function useWebModalLayerStyle(options = {}) {\r\n  const isDesktopFrame = useWebDesktopPhoneFrame();\r\n\r\n  if (isDesktopFrame) {\r\n    return {\r\n      position: 'absolute',\r\n      top: 0,\r\n      left: 0,\r\n      right: 0,\r\n      bottom: 0,\r\n      width: '100%',\r\n      height: '100%',\r\n    };\r\n  }\r\n\r\n  return {\r\n    position: 'fixed',\r\n    top: 0,\r\n    left: 0,\r\n    right: 0,\r\n    bottom: 0,\r\n    width: '100vw',\r\n    height: '100dvh',\r\n  };\r\n}
\n

That fixed the visual part. Then pointer events decided they wanted attention too.

\n

On native, pointerEvents=\"box-none\" is normal. On HTML, that turns into pointer-events: box-none, which is not real CSS, which means the browser gets to improvise. So there is now a defensive rule for the overlay host:

\n
.expo-web-app-shell #expo-web-modal-shell-host {\r\n  pointer-events: none !important;\r\n}\r\n\r\n.expo-web-app-shell #expo-web-modal-shell-host * {\r\n  pointer-events: auto !important;\r\n}
\n

There is also a useLayoutEffect forcing the same thing inline, because by that point I was no longer interested in finding out how polite the correct solution was.

\n

Look, I have a type

\n

If you’ve been reading this blog for a while, none of this should surprise you.

\n

I already turned this blog into a top-down RPG because the Konami Code deserved a bigger payoff than just a background effect.

\n

Then I added Stories to the blog because my internet provider’s app had Stories, and something about that annoyed me deeply enough that I made it everybody else’s problem.

\n

So yes, of course my fitness app now ships its website from the same Expo Router repo, and of course the desktop web app runs inside a giant picture of a phone. This is not a surprising escalation. This is just continuity.

\n

Why I’m keeping it

\n

Past the comedy value, this fixed a very real maintenance tax.

\n

Translations are shared. Design tokens are shared. Components are shared. Legal pages live next to the product they are legally defending. When I change copy, screenshots, or feature positioning, I don’t need to remember which repo holds the respectable public version of the same app.

\n

Deploy also got nicer. One build. One export. One artifact. The website and the web app cannot drift apart unless I deliberately make them drift apart, which is much harder when they are literally shipped together.

\n

And when I shipped the Musclog redesign, the website basically came along for the ride. Same spacing tokens, same colors, updated screenshots, same PR. Exactly the kind of boring maintenance win that makes a slightly weird architecture decision feel smart six months later.

\n

Conclusion

\n

Could I have kept the website in a separate Next.js repo like a more emotionally stable person? Sure.

\n

Was I ever going to keep doing that once Expo Router made this possible? No.

\n

The funny part is that the routing was the boring part. Expo Router handled that just fine. The annoying work lived in all the little browser lies around it: route gating before hydration, raw HTML i18n, asset syncing, shell-aware modals, pointer-event weirdness, and convincing desktop Chrome to temporarily believe it was a phone.

\n

Still worth it.

\n

If you want to poke around the code, Musclog is open-source on GitHub. If you want to use it, it’s at musclog.app. The website lives in the app repo now.

\n

Everybody lives here now.

","fields":{"postHashId":"Y29kaW5ndHJ1ZW51bGwyMDI2LTA0LTI1VDAwOjAwOjAwLjAwMFo=","slug":"/2026/2026-04-25-website-or-app-yes-hacky-expo-router-guide.en/","path":"/blog/coding/website-or-app-yes-hacky-expo-router-guide/","locale":"en"},"rawMarkdownBody":"\r\nOne of the annoying little side quests of shipping an app is that Google occasionally forces you to become a website owner too.\r\n\r\nBack when I [first wrote about Musclog in 2024](/en/blog/coding/musclog-leveraging-my-reactjs-experience-to-build-a-react-native-app/), the website mostly existed because Google wanted it to exist. I needed the privacy policy, the public pages, the whole respectable app developer starter pack, so I quickly spun up a small Next.js site, got the app approved, and moved on with my life.\r\n\r\nThat worked right until I had to touch the website again.\r\n\r\nNew screenshots? Other repo. New feature copy? Other repo. Legal page update? Other repo. Translation tweak? Other repo.\r\n\r\nNone of that was actually hard, which almost made it worse. It was just annoying enough to keep reminding me that I had split one product into two codebases for a reason I no longer respected.\r\n\r\nSo now I don't.\r\n\r\nMusclog's website lives inside the app repo. Same Expo Router project. Same deploy. [musclog.app](https://musclog.app/) is the public site, [musclog.app/app](https://musclog.app/app) is the actual web app, and Android + iOS still come from the same codebase.\r\n\r\nBest practice? Questionable. Convenient? Extremely.\r\n\r\n![Musclog public website rendered from the same Expo Router codebase as the app](../../uploads/blog/2026/04/musclog-shared-router-website-home-1.png)\r\n\r\n## Ok but why?\r\n\r\nBasically because Expo Router removed my last excuse.\r\n\r\nMusclog already used [Expo Router](https://expo.github.io/router/docs), so the app was already organized as file-based routes inside `app/`. Then I realized I could just create a route group called `(website)`, move the public pages there, keep the actual app under `app/app/*`, and stop pretending these were two different products.\r\n\r\nThe separate repo had become one of those architecture decisions that sounds clean in theory and then quietly charges you maintenance tax forever:\r\n\r\n- two PRs for one product change\r\n- two deployments\r\n- two places for translations\r\n- two places for legal pages\r\n- two places to forget something\r\n\r\nNo thanks.\r\n\r\n## The split\r\n\r\nThe funny part is that the routing itself ended up being the least cursed part of the whole thing:\r\n\r\n- `app/app/*` is the actual Musclog app. Workouts, nutrition, AI coach, all of it.\r\n- `app/(website)/*` is the public website. Landing page, privacy policy, terms, contact page, calculator.\r\n\r\nThe root route just checks the platform and sends you where you belong:\r\n\r\n```tsx\r\n// app/index.tsx\r\nimport { Redirect, useRouter } from 'expo-router';\r\nimport { useEffect } from 'react';\r\nimport { Platform } from 'react-native';\r\n\r\nexport default function Index() {\r\n const router = useRouter();\r\n\r\n useEffect(() => {\r\n if (Platform.OS === 'web') {\r\n router.replace('/home');\r\n }\r\n }, [router]);\r\n\r\n if (Platform.OS === 'web') {\r\n return null;\r\n }\r\n\r\n return ;\r\n}\r\n```\r\n\r\nThat's it. On web, `/` becomes the website. On native, `/` becomes the app.\r\n\r\nThe website also gets its own lighter layout:\r\n\r\n```tsx\r\n// app/(website)/_layout.web.tsx\r\nimport { Slot } from 'expo-router';\r\n\r\nimport { WebsiteChrome } from '@/components/website/WebsiteChrome';\r\nimport { WebsiteProviders } from '@/components/website/WebsiteProviders';\r\n\r\nexport default function WebsiteLayout() {\r\n return (\r\n \r\n \r\n \r\n \r\n \r\n );\r\n}\r\n```\r\n\r\nThat matters because the real app layout had already grown into an actual app layout. Database boot, migrations, React Query, safe area, gestures, modals, snackbars, camera, coach context, all the usual \"small side project\" lies. The website does not need any of that just to explain what the app does.\r\n\r\nAnd if a native user somehow lands on a website-only route, the fix is beautifully blunt:\r\n\r\n```tsx\r\n// app/(website)/home.tsx\r\nimport { Redirect } from 'expo-router';\r\n\r\nexport default function Home() {\r\n return ;\r\n}\r\n```\r\n\r\nDone. Back to your macros.\r\n\r\n![Musclog public website rendered from the same Expo Router codebase as the app](../../uploads/blog/2026/04/musclog-shared-router-website-home-2.png)\r\n\r\n## The desktop phone nonsense\r\n\r\nThis is where I stopped behaving like a normal person.\r\n\r\nI wanted [musclog.app/app](https://musclog.app/app/) on desktop to show the actual working app inside a phone frame. Partly because it looks nice. Partly because it doubles as a product preview. Mostly because once the idea entered my head, every less ridiculous option started feeling wrong.\r\n\r\nThe annoying detail was that `/app` should look like a phone, but `/home` absolutely should not. So routing alone was not enough. I needed the raw HTML shell to know, before hydration, whether the browser should render the fake phone wrapper or not.\r\n\r\nThat logic lives in `app/+html.tsx`, inside a script in the document ``:\r\n\r\n```tsx\r\nfunction landingPanelGate(base: string) {\r\n try {\r\n function update() {\r\n const raw = window.location.pathname;\r\n const path = (base && raw.startsWith(base) ? raw.slice(base.length) : raw) || '/';\r\n\r\n if (!path.startsWith('/app')) {\r\n document.documentElement.classList.add('hide-desktop-wrapper');\r\n } else {\r\n document.documentElement.classList.remove('hide-desktop-wrapper');\r\n }\r\n }\r\n\r\n update();\r\n window.addEventListener('popstate', update);\r\n\r\n const origPush = history.pushState.bind(history);\r\n history.pushState = function (...args) {\r\n origPush(...args);\r\n update();\r\n };\r\n\r\n const origReplace = history.replaceState.bind(history);\r\n history.replaceState = function (...args) {\r\n origReplace(...args);\r\n update();\r\n };\r\n } catch (_) {}\r\n}\r\n```\r\n\r\nThe important part is the `pushState` / `replaceState` monkey patch. First paint was easy. Client-side navigation was the annoying bit. Without this, you could leave `/app` and keep the wrong shell around like Chrome had forgotten what page it was on.\r\n\r\nThe HTML shell itself is basically the landing panel, the routed app, and the phone frame:\r\n\r\n```tsx\r\n\r\n
...
\r\n