erikpoort / react-native-native-navigation Goto Github PK

These will be available through initialProps in the component.
Values can be strings and numbers, not arrays or objects.
The reason for this is to limit bridge abuse. If you are restricted to simple data, you won't be sending massive data objects through te bridge, which could slow down performance.
Instead, you'll have to save the data in redux for example, accessing it by a passed id.

Make possible to change dynamically nav buttons titles.

If the js code is sharing a string const with native code, these constants should be exported by the native code.

It seems that you can have nested stacks (uinavigationcontorllers) inside the simulator, but not in a release build on iOS. So there needs to be nested stack validation.

For example, when you have a split-view, you should be able to replace that split-view with a single-view.
Drawer can already replace all sides.
Tabs should be replaceable.
Splitview sides should be replaceable.
Navigation root should be replaceable.
Stack root should be replaceable.

ReactNative will deprecate componentWillMount and componentWillReceiveProps soon

For example, the drawer could easily use an enum for defining the side.
So could the splitview with first/second.

These should be defined in the native side and exported to js.

When the main Navigation tree, or any Component which provides it's own structure, changes it's tree, this should be reflected on the native side.

For example:
An app with a drawer has Home Component as center view.
The Home Component has a render method, that shows either a stack navigator, or a single login page. This is based on a prop and can be switched at any time.
When switching from stack to login (expired token in background), the native stack should be cleared and the login should be shown.

It should be able to add nodes from outside of the framework.
Say your project needs a special type of tab bar, this should be possible without fork.
The user needs the ability to provide their own nodes, both js and native data should be provided implementing certain interfaces.

Push and showModal are very similar, these should be abstracted one generic method.

We should come up with a good name for the components.
Currently we have nodes / data / navigators and components.
We should also group these, instead of having a folder with all viewmodels and a separate one with views.

Just like the drawer, you should be able to replace a side

this.props.stack.push(<SingleView {...props} />, true) is crashing the app.

This could be done by removing and adding tabs without animation.

It is important to be able to reset the root of the entire navigation.
Like having a login view, which replaces the root with a drawer after successful login.

When for some reason, you need to nest two stack navigators, you need to be able to call push on either of these navigators.

Options:

• this.props.<stack_name_or_path>.push()
• this.props.stack.stack.push()
• this.props.navigation.stackForID(<stack_path>).push

You should be able to set a lazy-load flag.
Example: When initiating the app with a 3 page step, you should be able to specify if all three components should me started, or just the latest, loading the other two when they become visible.

It should be possible to specify an app structure inside a page.
For example:
You are in the onboarding, and when done, you push the Home component.
Inside the Home component, in the render method for example, a drawer node with a menu and a stack node is defined.

If you change the center view in the drawer for example, the old view should be properly destroyed.
This issue is more a reminder to check if that is currently done.

It should be possible to push a node to a stack or modal view.
For example pushing a tabbar in a stack view.

On Android, ReactNative doesn't seem to be listening to keyboard strokes.
Using R R should work anywhere in the app.

Nesting a lot of nodes can result in really long screenIDs, which are build as breadcrumbs. Screens should be registered with smaller IDs, or rebuild in the native part.
Using smaller IDs takes away some readability, but adds a base for defining userbased path names.
Rebuilding in the native part is prone to error, especially when adding new nodes.

If a stack has multiple views, calling updateStyle on all three of them shouldn't have unexpected results.
Imagine three views, with three different titles and js trying to change all of these title to another language. You shouldn't see the first view's title on the third view.

You shouldn't have to specify all used pages in the Navigation tag, this causes annoyance during developing. All nodes should be able to provide new pages.

The root should be replaceable.
Possible solutions could be the use of resetTo or a custom solution. The custom solution would be due too android.

Only the root should be replaceable, otherwise you can just pop and push with animation.

If you start using a new navigation library, you want to be using the newest RN version anyway.

Currently, If the user opens a view from a side menu, the side menu closes automatically. The user could be able to set if the side menu should either close, or still open.