Platform specific optimizations using webpack

As you may have noticed, inside the react-native sources you may find a lot of files suffixed as .android.js or .ios.js, and you may wonder why. How they work is pretty simple, when you are building with the react-native packer over android or ios, the file suffixed with the platform name is preferred and used instead of the .js ones.

Having a per-platform suffix on webpack

So you can just define a suffix per-platform and you are done! Inside that file you can extend or even override the default behaviour. But that's a feature of the react-native packer... right?

Yep, but that could be done by prepending an element to the webpack config resolve.extensions, and your webpack will prefer, for example, file prefixed .winphone.js over the .js regular ones.

Use dumb components where possible

While writing your app, you will understand that some high order, or smart, components does not use in any way platform-specific components like <View/> or <div/>. These components are just containers of smaller, or dumb, components. For example a LoginForm component may be smart component, since it is only a container of dumb components like UserInput, PasswordInput and a SubmitButton.

So... even react-native components may be considered dumb components!

You may figure out next that even react-native basic components may be considered dumb components, and so as we pointed out before we can use suffixes to switch between platform-specific implementation of the same component with the same API!

That's what basically react-native-for-web is. A set of dumb components for react-dom written with the same API of the react-native ones.

Suffixes in react-native-for-web? WHY?!?

Platform suffixes becomes a powerful feature in react-native-for-web. Since react-native-for-web autogenerates web-based views, they will not perfectly look and feel like the native ones for the platform you are developing to. You can use suffixes to perform changes or override the autogenerated components.

So autogenerated web components will be used as a base for platform specific dumb components, that will override or extend the autogenerated ones. You should consider the autogenerated ones as a "gift" or a "rent", you will have them for free, but they will not be exactly how you want them to be.

So why use react-native-for-web?

As pointed out before, you will have for free web components that "works". This means that you can use the 3 weeks given before the client deadline to develop a fully functional and awesome react-native app over iOS, and don't lose time on developing an android one.

The android one will be done in an hour or less by just using react-native-for-web over a cordova container, and you will have a "working" app with no effort over android.

Now that the client is satisfied because the iOS app is awesome and the android one is working but not so awesome, you can have extra time to do the finishing touches to the android version, providing extra platform specific dumb components.