Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
  • Jun 24 23:53
    mkonicek removed as member
  • Jun 14 01:21
    lauraskelton added as member
  • Nov 05 2020 21:34
    spikebrehm added as member
  • Mar 17 2020 19:12
    benkraus closed #72
  • Mar 17 2020 19:12
    benkraus closed #95
  • Mar 17 2020 19:11
    benkraus closed #68
  • Mar 17 2020 19:10
    benkraus closed #73
  • Mar 17 2020 19:10
    benkraus closed #78
  • Dec 20 2019 18:15
    nfcampos closed #111
  • Dec 20 2019 18:14
    nfcampos closed #122
  • Sep 05 2019 04:46
    BenSchwab edited as member
  • Sep 05 2019 04:45
    lelandrichardson edited as member
  • Sep 05 2019 04:44
    gpeal edited as member
  • Jun 27 2019 15:04
    Arlevoy closed #165
  • Jun 27 2019 15:04
    Arlevoy opened #165
  • Mar 26 2019 17:01
    yassinecc closed #164
  • Mar 26 2019 17:01
    yassinecc opened #164
  • Dec 21 2018 12:20
    renatoagds closed #127
  • Nov 10 2018 07:25
    felipecsl added as member
  • Oct 24 2018 07:43
    arufian closed #163
Ben Kraus
The shared elements and whatnot
Though, still a ways from defining your own transitions and whatnot
Nuno Campos
i tried to implement this for custom react views inside the nav bar but couldn't get it to work (admittedly i didn't try too hard)
but i did end up questioning the approach of portals v just rendering a new react root view inside e.g. the nav bar
Nuno Campos
what's the advantage of using a portal?
Leland Richardson
@nfcampos using a portal would be rendering a new react root view inside the nav bar, but the contents of it would be decided in the render function of a different root view (the screen’s) which is what makes it a portal
Nuno Campos
then we're speaking of the same thing
you'll find a fairly primitive implementation of this in a PR on the repo. i've since closed the pr because i couldn't get the positioning/transitions working correctly
Leland Richardson
the positioning/transitioning is indeed the tricky part
and i have some ideas around this
i think it would involve making native animated nodes implement CALayer dynamic properties: https://www.objc.io/issues/12-animations/animating-custom-layer-properties/
which would allow us to drive animated values from native, and from things like UITransitionCoordinator
which would be pretty cool
on android i still don’t know exactly how we’d do it but i think it’s possible now that we are using fragments
the portal stuff might be useful even without the transition support though
but obv. not quite as generally applicable
Nuno Campos
that looks interesting
the portal part i have a fairly good idea of how it can be implemented, ie. how to get this API working <Navigation.Config titleView={<MyCustomView onPress={() => doSomething()} />} />
which would require always on the native side rendering the same Portal component with some id as a prop that then maps on the js side to an element to render
this avoids the props going across the bridge, which would prevent having functions as props etc
this plus some of that transitioning magic should make for a pretty nice experience
Ben Kraus
We actually have functions as props being passed around working. Doing pretty much the same thing as Wix there- a prop "registry" where it sidesteps native
It does essentially that - never sends them over the bridge
Nuno Campos
i suggest having an element registry so that you don't have to registerComponent all components rendered in a portal, the only one registered is the portal itself
Leland Richardson
yeah we can send function props no problem
but i try to dissuade people from doing so across screens
since we want screens generally to be deep linkable
but sometimes there’s a good reason for it
for things like portals into the navbar and stuff though there would be very good reasons to have function props
Nuno Campos
yep i want a search bar on the nav bar
on another subject, i'm not sure i agree with the Tabs/Tab api
Leland Richardson
yeah? which part?
Nuno Campos
having them as "fake" components has 2 issues for me,1. it delays knowing which tabs to display, which is important since tabs are (usually) the first thing you see when you open the app
  1. it is confusing because you can't actually mix them with any other react component, kind of like Route component from react router before v4, i think people will expect/try to mix it with other react components and be surprised it doesn't works
Leland Richardson
the tabs API isn’t used at airbnb, so it’s definitely one of the APIs that has some lee-way
Nuno Campos
(sorry about the confusing layout that was supposed to be 1 and 2)
personally i'm not using the tabs api at all, because of the points above and a bug that it has somewhere, in just doing it on the native side
but i understand that's not a valid solution for a react native library
Leland Richardson
yeah i was attempting to solve it the best way i could think of for being controlled from JS side
the delay is an important point
Nuno Campos
yeah, and also, when you're using tabs on ios as the root view controller you maybe also want to have the launch screen have the same tabs, so it'd be nice if that could be done by the library as well (but this sounds like it'd need some build time code, which i don't know if it's possible in a react native library)
Ben Kraus
I for one would love to see the tabs API a little more "greenfield"
I actually started down that path and ran into a couple issues. Shouldn't be too hard to resolve
Just to find time...
Iván Villamil
Does the Shared Element transition work for both iOS & Android?
Kwame Adjei
@lelandrichardson Can we get a github issue around installation? As per the readme i understand that installation is expected to have drastic changes on the road to v1. I'm exited to try native-navigation but due to the installation requirements, i'm holding off until the library can be used without the os specific boilerplate. I love what you guys are doing. Sadly i'm in no position to contribute due to my limited knowledge in native development but i'm very happy that there's a well thought out library to fill the react native navigation gap.
Rumen Rusanov
Hi guys, I didn't see any information about how you can use pushNative or any other native controller call. I checked the native code and it's look like you have to register the controllers that you want to present/push from react native but I'm not really sure. Is anyone try this or know how is suppose to work?
Paul Matyukov
Hello all! There is an issue with reloading -> I have screen component (CheckLogin) it make decision: show app or show login - so every time when i reload(dev mode) - all viewControllers in coordinator still exist and push one more. Maybe i do something wrong? Also i want to try implement Tabs without native part - any advices where to start?)
Madhava Jay
// index.ios.tsx
import Home from './home'
import Login from './login'
import Navigator from 'native-navigation'

Navigator.registerScreen('demo', () => Login)
Navigator.registerScreen('Home', () => Home)

// login.tsx
import * as React from 'react'
import Navigator from 'native-navigation'
import {
  } from 'react-native'
import { styles } from './styles'

export interface Props {}
export interface State {}

export default class LoginScreen extends React.Component<Props, State> {
  render() {
    const onPressFunction = () => {

    return (
      <View style={styles.container}>
          <Text style={styles.welcome}>
            Welcome to React Native! (in TypeScript)
          <Text style={styles.instructions}>Please Login Below</Text>
          <View style={styles.buttonContainer}>