Opinião sobre código. login com react-native, contex api, firebase

[romulosardinha]

Gostaria da opinião de quem puder sobre meu código:

https://github.com/rmlSardinha/login-react-firebase

Apenas os códigos referentes ao login de rotas correspondentes ao tipo de usuário.

[ninetails]

Seria legal se tivesse a aplicação inteira (claro, sem os secrets etc) pra rodar local, mas como foi pedido apenas sobre código:

(lembrando que o que posto são só sugestões, podem não ser pertinentes)

routes.js

Criar uma factory enquanto não virar algo complexo

({ homeScreen, title }) => createAppContainer(
    createStackNavigator({
        Home: { screen: homeScreen },
    },
        {
            defaultNavigationOptions: {
                headerTitle: title,
            },
            mode: 'modal',
        })
)

Deixar cada rota em um arquivo

routes/
  Adm
  User
  Offline

Evitar `if` inline complexos

Caso forem somente os 3 casos:

export default Routes = () => {
  // ...

  if (global.logged === 'offline') {
    return <Offline />
  }

  if (global.profile.type === 'adm') {
    return <Adm />
  }

  return <User />
}

firebase.js

Importe a config via environment variable

const config = {
  apiKey: process.env.API_KEY,
  authDomain: process.env.AUTH_DOMAIN,
  databaseURL: process.env.DATABASE_URL,
  projectId: process.env.PROJECT_ID,
  storageBucket: process.env.STORAGE_BUCKET,
  messagingSenderId: process.env.MESSAGING_SENDER_ID,
  appId: process.env.APP_ID
};

e aí usar dotenv local (deixando o arquivo .env no .gitignore) e em produção, deixar isso setado no hosting

MAS acho que o Firebase já tem algo, vale a pena dar uma lida.

Fragment com apenas um child, retorne direto

return props.children

:D

[romulosardinha]

Muito obrigado @ninetails !
Vlw pelas dicas! me ajudou bastante!

[romulosardinha]

Qual é a maior vantagem de ter cada rota em arquivo separado ?

[ninetails]

São sugestões pessoais, não se sinta pressionado a utilizar e se não fizer sentido, pode ignorar sem problemas ;D

Mas explicando bem por cima seria meio que uma mescla de intenções:

• Modularizar (que no caso já estão)
• Deixar apenas uma função por arquivo

Na verdade esse segundo é meio que uma adaptação do que a galera do Java falava de boas práticas deixar uma classe apenas por arquivo. Porém também tem o contraponto de que criar arquivos a rodo com funções pequenas também pode fazer tua aplicação perder legibilidade.

Minha intenção para rotas em específico foi de deixar claro já na listagem de arquivos mostrar quais rotas sua aplicação possui (sem nem precisar abrir o arquivo de rotas). Pois também fica meio claro que para criar uma rota nova precisaria duplicar uma das rotas existentes e adicionar no arquivo de rotas depois. E é um padrão já existente em alguns frameworks como Next e Gatsby.

Também era intenção diminuir a formatação vertical do arquivo de rotas (Clean Code). Mesmo que um arquivo esteja bem estruturado, é meio ruim ter um arquivo que pra navegar precise dar vários Page Down ou fold e unfold de código. Também trazer a lógica de rotas que ficava lá embaixo pra cima, extraindo cada componente de rota em arquivos próprios.

Porém se vc fizer a factory talvez já diminua o tamanho do arquivo e nem precise dividir em mais arquivos de rotas, resolvendo o problema acima. Dividir em mais arquivos é meio que um overengineering que talvez nem precise enquanto escalar rotas não for problema.

[romulosardinha]

Eu deixei as rotas no mesmo arquivo exatamente pelo motivo do seu 3º parágrafo

Adorei a razão do 4º parágrafo... me convenceu kkk vlw @ninetails

[ninetails]

@rmlSardinha show ;D

Então, não existe absolutos, nem mesmo pro John Carmack (sobre funções inline). Aí é bom senso e consenso dos devs do projeto adicionalmente misturando com outras fontes, como no caso, sobre a formatação vertical meio que vem do Clean Code (que pegou de outras n referências) e que tb fala sobre formatação horizontal.

^{_{(na verdade eu só respondi pq queria sharear esse link do John Carmack bem pertinente ao assunto rs)}}