[JS] New 'react-native init'

[mkonicek]

'react-native init' should have an option where it creates a small app for you, using best practices. Right now 'react-native init' creates an "app" for you which is useless. I have to go and read lots of documentation and tutorials to figure out how to do completely basic things like navigation and state management. We have a great opportunity to make 'init' create something useful.

The new template would be a small app that includes Navigation, one screen with a ListView that renders JSON data fetched from a HTTP endpoint, and Redux for state management. It should also include tests.

We should include a basic local node server that serves the data and stores updates in memory, so that you can do 'init', run and see the whole thing working end-to-end.

For this, previous experience with building RN apps is essential.

You can implement this in steps, by first implementing a subset:

• react-native init --navigation creates an app with a ListView with static hardcoded items, tapping an item takes you to a screen representing that item
• react-native init --redux creates an similar to the above, plus uses Redux for data management, and also allows editing the data via the detail screen. For this there should be a small local node server included that the user can start with a simple command.

See the discussion: https://www.facebook.com/groups/reactnativeoss/permalink/1558844321078863

This might be a good writeup to look at: https://medium.com/@dabit3/first-look-react-native-navigator-experimental-9a7cf39a615b#.656joiyks

[mkonicek]

Please do this without using Yeoman generators. We want to remove Yeoman from the tree because it has too many dependencies.

[satya164]

Happy to give it a shot next week. I already have working code which generates a project from a template. If anyone wants to help me with this, please ping me.

[satya164]

BTW, should we wait for NavigationExperimental to be stable?

[mkonicek]

@satya164 I'd be fine with using NavigationExperimental in the template. Hopefully it will be an easy codemod later :)

[mkonicek]

@ericvicenti Do you have a rough ETA on removing the Experimental suffix? Will it be called Navigation?

[ericvicenti]

The NavigationTransitioner is very close to stable, so that can be moved to the normal core soon because we're using it at Fb. But there are other parts of NavigaitonExperimental like the Header and Card which aren't used by Fb in production, and they should probably be maintained by the community. Ideally somebody would own those outside of the RN core, otherwise they may be experimental indefinitely.

[Ehesp]

@ericvicenti The whole Navigation scene in React Native right now is a mess. We've got Navigator which is being deprecated support wise, and NavigatorIOS which is maintained by the community, and I believe will also come deprecated once NavigatorExperimental comes out (or will it?).

With your above comment it just adds to the confusion/mess. If one part of NavigatorExperimental will be maintained by Facebook and one part by the community, won't we have just another Navigation solution which sorts of works - but isn't great since it might not be kept up-to-date by the community?

In my opinion, we need a single Navigation solution which is fully supported with great documentation - right now every time I see/deal with a RN app navigation feels like a hack to get it implemented.

[mkonicek]

@ericvicenti Thanks for replying! Is it going to be called NavigationTransitioner or can it be simply called Navigation? (I vote for the simple name if it makes sense to use it.)

[mkonicek]

But there are other parts of NavigationExperimental like the Header and Card which aren't used by Fb in production ...

@ericvicenti It doesn't matter that much we don't use some parts of this at fb in production yet. Can you choose opinionated defaults that work well for open source? If it involves components that we don't use internally at fb yet that's fine. It's more important to have a clear "go to" solution we can document and anyone can use and adapt easily.

... and they should probably be maintained by the community.

Anything that lives in the react-native repo is maintained by the community, as well as the RN team. Some parts mainly by the community. It's fine to have the Header and Card in this repo if it helps the open source use case. It will get maintained as navigation is one of the most used APIs in React Native.

[ericvicenti]

Sorry that things are currently a mess! It is difficult for me to keep things sane for the community while continuing work on internal projects. But I'd really like to help clear things up.

@mkonicek I see your point and agree that it makes sense to ship RN with opinionated default components. I'd like to propose these modules/names for un-experimentalizing:

Navigation - Namespace for these modules to avoid muddying the react-native namespace
Navigation.Transitioner - Coordinate animations between scenes
Navigaiton.StateUtils - Utilities to help modify the navigation state for your app (push, pop, etc)
Navigation.Card - Default scene component that looks platform-appropriate
Navigaiton.Header - Default header component that looks platform-appropriate
Navigation.CardStack - Default integration of Transitioner and Card (and possibly Header). Behaves like a declarative Navigator

As far as the existing components go:

Navigator - Will be deprecated as we un-experimentalize the things above
NavigatorIOS - Will NOT be deprecated, but we need somebody to switch it to a declarative API like that of CardStack

We can switch these things over as soon as we kill NavigationAnimatedView, by moving CardStack to depend on Transitioner instead.

cc @hedgerwang