React-native: [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

[lacker]

Are we really ready to deprecate Navigator? I think before we deprecate it we should have a clear migration guide from Navigator to Navigation, and make sure there aren't big missing components. We don't want to leave things in a half-deprecated-but-not-really mode like NavigatorIOS currently is.

[jmurzy]

@ericvicenti Is there anything the community can do to help move to forward faster? Now that the API is close to stable, it would be great if you or @hedgerwang created issues for things that need to be done before 'experimental' can be dropped. I am happy to help out.

🍺

[ericvicenti]

@jmurzy, Thanks for offering! I think the main thing that needs to be changed at this point is to move NavigationCardStack over to NavigationTransitioner rather than NavigationAnimatedView. It should be pretty straightforward if you want to give it a shot! Filed as #8262

@lacker, I agree we should put together a migration guide. With some very minor cosmetic differences, NavigationCardStack can support anything we did with Navigator- let me know if there are any use cases which we don't support yet!

[jmurzy]

@ericvicenti Having done that sorta migration at least a few times over the last couple weeks, that shouldn't take too long. Will report back.

🍺

[lacker]

We should be sure to make our docs that talk about navigation encourage the same "best practices" as a new-app template creates for you. cc @hramos who is working on navigation-documentation. Also we should be sure that our navigation docs get updated with the precise messaging about when/what is deprecated.

[lacker]

This has kinda turned into a couple other projects like create-react-native-app so I think this issue has served its purpose and should be closed. Thanks folks for chiming in!