callstackincubator / rebolt-navigation Goto Github PK

The new header API uses renderLeft, renderRight and renderTitle. We need to adjust the implementation of iOS to follow that.

Right now, we rely on our fork. We need to talk to the maintainers and ask them to transfer the repository to paper organisation where we would be able to keep working on it in a bit faster way.

I am in the middle of the process of making the header work. Right now, I have a simple structure and working on the animations.

Once sorted, we need to figure out the most optimal and least confusing API for the header configuration.

I will ping everyone interested in a day or two to discuss this more in detail.

The following are in scope for v1 release:

• Follow iOS behavior when it comes to back button, that is, convert to "Back" when it doesn't fit
• Support hiding by providing an alternative animation config
• ...

Ideally, we want this library to support pure Javascript React Native applications. I know that @knowbody did some research on that topic, so going to leave the details of this issue up to him.

The best plan would be to have JS & Flow generated code available for npm users.

Instead of removing scene inside POP, change the index and by using onTransitionEnd callback, make sure to remove all stale scenes.

That will give also support jumping back.

Currently, the TabNavigator doesn't support all possible cases, we need an API that will respect these and more:

the list provided by @satya164:

1. iOS style tabs, no animation or gestures,
2. material top tabs, slide animation, swipe gesture,
3. material bottom navigation, cross-fade animation, no gestures

I'm not sure if we want to have a few different navigators for this, I would more like to have a single TabNavigator API that will allow users to do all of these things.

Thoughts?

Readme and docsite installation and configuration instructions differ. Readme says install reason-reroute and docsite says instal reroute, same for updates to bsconfig.

Make a Card component that has platform-specific styles (iOS/Android) including different platform-specific animations.

Also, expose Animation.platformDefault (or something similar).

Steps to reproduce

1. Create a navigation screen with animation prop set to Animation.none:

<StackNavigator.Screen headerTitle="Settings" navigation animation=(Animation.none)>

2. Push it to StackNavigator
3. Screen appears without animation
4. Click back button on header

Result

Right now, there's white flash between different transitions. I am pretty sure this has been already fixed somewhere, need to check.

Possible solutions:

• add it to dependencies instead of devDependencies
• add some information in Docs that it is required

I have troubles discovering the codebase without reis but from my brief look at Animation.re it seems sort of redundant. I find the Animation module an undesirable solution for the animation problem because it tightly couples animations to an architecture selected by this library. I find it redundant because in the examples we can see that the routes are wrapped in the Screen component which should probably handle animations by itself (and contain said configs). I understand that there are other components like Header that come into play but such tight coupling was a footgun in react-navigation from my experience (when I had a sort of custom set up but it wasn't that complex either).

For instance, ReRoute has a module called Utils which is pretty generic and will conflict with the project using ReRoute as dependency.

Any reasons why namespace is set to false currently?

cc @medson10

Any action (Push, Pop) to start with should only be accepted if it's from an active screen. Quick and easy win.

Implement LazyRoute component for declaring Header and all that stuff but w/o rendering the content itself.

So far, the animation API depends on the scene index that we interpolate. We should make it always 0,1 to allow composing different animations and remove requirement of animation handling both cases.

Why don't we use react-native-tab-view with bindings instead? Looks like most of the work could be easily avoided. It is a nice foundation that react-navigation and other libraries use.

Anyway, below is my feedback that I'll be updating as I click through the app:

• iOS / Android should use platform default style (use custom code, e.g. with react-native-paper or use Satya's library entirely, that is react-native-tab-view).
• when renderTabBar is removed, it doesn't render anything
• example app is blank (doesn't render content)
• instead of renderTabBar, favor tabBarComponent (just like I did in StackNavigation)

Implement iOS 11 header style (hide it under an option on screen -> large: true)

Planning to launch private beta tests this week, let's prepare sane documentation and getting started guide for people.

I will try to wrap it up either today or tomorrow (rather the latter).

Ideally, using react-native-gesture-handler

Align it better with the TabBar API (provide headerComponent)

We have MaskedViewIOS and TouchableNativeFeedback in progress, would be great to do them as a PR to bs-react-native.

@wokalski can I count on your review here so that sending PR to bs-react-native is going to be just a matter of merging?

when you try to drag back on the initial screen this is being thrown, we need to prevent it if only one route on the stack:

Version 0.5.0 from npm isn't enough

When I give a headerTitle prop an empty string I get this (which is what I expect):

but then without headerTitle prop, I get something like this:

not sure if headerProp should be there always or we should have a default empty string if it is not provided?
cc @grabbou

Right now, header interpolator is part of animation you define for screen. We need to make them separate and optionally provide headerInterpolator prop on StackNavigator (only when requested). That will make working with custom animations way more simple.

I'd argue that any navigation library is at the same time a state management library. It's because conceptually (and state wise) when you go (for instance) from a list of categories to a category you moved (in abstract terms) from a parent to a child. Besides the abstract connection, you usually (in some way) pass stuff down to the children.

Not coincidentally the data flow of the app usually resembles the navigation hierarchy.

It's especially true in the case of Reason where passing props down is the dominant approach for two reasons:

1. It's not error prone
2. You can sort of specify the types when you pass them down. I.e. when you go from a list categories to a category you are sure that a given category exists in the application state. When you have a global state, let's say in the form of a dictionary (map), the result of getting state["id"] is option('a). However when you pass props down you're more likely to pass 'a directly to the next (child screen). That way you remove "impossible" states.

It sorta kinda can be done with the current approach. After all variants can contain payload. It's not enough though because there's no way to make updates to the parent state using this approach. If you look closely there's no mechanism which makes the "child screen" update when the "parent screen"'s state changes.

I should mention, that I had this kind of navigation (a pretty much the same API) in a real world app a few months ago and I didn't like the outcome. On the other hand, this problem is sort of dear to my heart 😛.

Before I elaborate on my solution to this problem, I'd like to hear your thoughts. Mainly - do you share my concerns? If not, how are you planning state management in apps you want to build using this library?

We need decent documentation that will talk about all the great APIs and customisability we have prepared for our users - I am pretty sure they gonna love it!

Anyways, Docosaurs seems to be the thing right now. Open to other ideas too.

We need to apply appropriate pointerEvents to header layer and card that is no longer active (and supposed to accept any interactions).

What to test and how

Currently there are no animations in TabNavigator

reason-reroute is horribly out of date on npm.
reroute on npm (which is mentioned in docs) looks unrelated to this project.

after trying to run example from master I get this error:

installed all dependencies etc.

Make a default Android transition (as opposed to slideIn being iOS default) and a new header, which will be like FloatingHeader, but not floating :)

After moving files around to .native folder (a quite cool idea hiding abstraction), I couldn't run the app with react-native command line tools - had to go over to XCode and hit run manually by selecting appropriate .xcodeproj. This should be fixed for better developer experience of others.

Thanks a lot for the hard work on this library!

I wanted to make you aware of an inconsistency between the StackNavigator and TabNavigator APIs. For the TabNavigator, the initial route you pass is to a prop named initialRoute which seems perfectly fine, but for StackNavigator, the prop with the same purpose is named initialState. I'm not sure if it was intentional to name it that or if it was a typo of sorts, but I feel that if it were renamed that it would be easier to remember between navigator types.

https://github.com/knowbody/reroute-native/blob/master/src/TabNavigator.re#L296
https://github.com/knowbody/reroute-native/blob/master/src/StackNavigator.re#L258

Thanks!

reis are really helpful for documentation. Both when it comes to the documentation of changes (you can see all changes to a .rei in git and therefore get a sense of how the public api has changed) and the documentation of the API itself.

It's also frankly pretty hard for me to understand the API surface without it.

The title of this issue the error message I receive when I try to run the code from the example in my own project:

/*  NavigationConfig.re  */
module Config = {
  type route =
    | Welcome
    | Reminders
    | Reminder
    | Tasks
    | Task
    | TaskPomodoro
    | Stats
    | Settings;
};

include ReRoute.CreateNavigation(Config);

Any idea why that may be? Autocomplete only shows CreateRouter but thats probably not what I should use.

For Android less than KitKat, we need to use TouchableHighlight. I'll work on that.

Currently, there is no way to hide a header in StackNavigator

Currently, when doing push transition, we need to read animation config from the pushed route. Unfortunately, it's options are set one tick after the transition starts. That results in default animation being triggered all the time.

We need to either setOptions earlier or change the didUpdate logic to run animation after the render happened.

CC: @satya164

Right now, in order to require an image, I have to write require('../../../../src/assets/a.png') just because my code doesn't run in src, but in lib/.. along with other compiled Reason code.

Is this approach "standard" (the path seems a bit ugly and non-scalable) or there's a better way of doing that?

CC: @knowbody since you may have run into that already

Time to drop react-navigation and use something better with a proper logo concept.

We need Android support. Going to work on it right now + create fade interpolator to use on Android.