Better API

[baransu]

Current API is exactly the same (or similar) as original JS react-navigation API. It has it's limitations and in Reason it doesn't work so well. The ideal navigation definition would be done using variants. It allow to have very strong types, pass params to specific screens or event create special mapping between deep linking and navigation.
Here is some quick sketch of something I have in mind. Only thing I'm missing is how to convert it to react-navigation API.

type routeConfig('route) = {
  screen: (~navigation: navigationScreenProp('route)) => ReasonReact.reactElement,
  navigationOptions: option(unit),
};

type stackNavigatorConfig;

module type Config = {
  type route;
  let pathToRoute: list(string) => route;
  let routeToScreen: route => routeConfig(route);
  let stackNavigatorConfig: stackNavigatorConfig;
};

module Config = {
  type route =
    | ProductsList
    | Product(string);

  /* for deep linking we can convert path to route */
  let pathToRoute = path =>
    switch (path) {
    | ["products", id] => Product(id)->Some
    | ["products"] => ProductsList->Some
    | _ => None
    };

  let routeToScreen = route =>
    switch (route) {
    | ProductsList => route(
        ~screen=(~navigation) => <ProductsList navigation />,
        /* Whole navigation configuration per screen */
      })
    | Product(id) => route(
        ~screen=(~navigation) => <Product navigation id />,
      )
    };

  let stackNavigatorConfig = {/* ... */};
};

[bsr203]

Thanks for your effort on this. Before you update this package, I was adapting binding from this. As a binding to react-navigation, I am not sure it worth the effort to radically change the API to make idiomatic with ReasonML. I am sure you also seen rebolt

[baransu]

rebolt-navigation is great but it's build from scratch. I would really like to contribute more to have true Reason navigation library for React Native. This library started as my experiment to see how hard it would be to create bindings to react-navigation and still I'm not sure if this is right direction.

[baransu]

@bsr203 I'm playing a little bit with the API here. Idea is to use any Reason data structure for params (like polymorphic variants) to pass different types of payload between different routes. Having param type bound to screen rather than whole navigation forces you to define param type when you get params rather than set them. I think it's better to have one data structure with multiple states.

Let's imagine application that displays list of products and single product details. You can define your params as:

type params = option(string)

so you set it to None by default and then, during transition you pass Some(productId). For 2 screens navigation it's ok, but lets imagine more complex navigation. Let's say we have products with details and screen that allows you to pick quantity of the product. Then we can define params as:

type params = [ `Initial | `Product(string) |  ProductQuantity(string, int) ]

which is more flexible.

Similar situation is with routeName as a string. But thanks to [@bs.deriving jsConverter] you can transform polymorphic variants to string and use variants during navigation.

It's only experiment. This library is not production ready. Soon I'll be starting large Reason React Native application so probably I'll use this library internally and iterate over the API during the project. I hope this will validate mu assumptions and allow me to make this library production ready.

[bsr203]

Thanks @baransu for your work on this. I will get back to using it in few days, and will give my feedback. I can't wait to see the improvements as you started using it heavily. Cheers.