Renaming the package

[mattiamanzati]

Yeah, it's the second time. I know.
The thing is that I don't want to compete or create misunderstanding with @necolas, since our two packages have a similar name but two different objectives.

The thing is: How to name it?
Right now my best choice is to roll back to react-native-web-polyfill, but I don't kinda like it because "Polyfill" is a discussed terminology, and as exposed in the readme, the objective of this library is not to replace react-native for ios or android.

What do you guys think about it?

[mattiamanzati]

Also react-native-for-browser, but still similar to necolas one.

[necolas]

…or is my repo badly named? I wonder how much code we might be able to share between our projects.

[chandu0101]

i wish both projects merge at some point in time. as react-native-web is just a subset of react-native-for-web , we get quality components/styling/touch.. when both sharing work! . that being said my gut feeling is facebook will release their native-web version in future!

if both of you agreed to work together then i vote for react-native-web as project name :)

[mattiamanzati]

I slept on it and I had an interesting idea over micro-modules, so maybe @necolas we can share a lot of common codebase, and maybe even merge our packages.

• precompiled CSS stylesheet that contains defaults and helpers for components to work (as it's right now), I love less, because the user can then import and namespace it, but plain CSS stylesheets may be enough.
• run-time (I also wish for a build-time maybe over jsxstyles) CSS translator which takes in a react-native style definition [{height: 10}, {width: 20}, null, undefined] and translates it into a single valid CSS object. This will be used for non-default styles, like the ones passed by prop from the user or computed by the "web" components on the fly and appended to the component. At the moment "for-web" rely on Radium, but I would like to remove this dependency as it is only for vendor prefixing.
• subset of react-native components, this package will depend on the styler, and will contains all react-native components that are not platform specific like Text, View, ScrollView, Navigator, TouchableHighlight, TouchableOpacity, etc... the main point is that they will have the same props as the ones in the docs, plus some other properties, and pass down to the main node unrecognized properties. This will includes also implementation of touch events and onLayout and similar events. This is mostly what react-native-web does. I would love to also integrate responders in this module, since they are a neat concept.
• main react-native utility classes I think that modules like StyeSheet, AsyncStorage, Animated, PixelRatio could be converted and shipped as a package that depends on the components one, or ship them together.
• web specific components and classes backed specially for browsers, and following the react-native idea of suffixes, like "SliderWeb", SwipeableWeb or similar ones.
• web polyfill this module try to introduce the missing classes to allow what react-native-for-web does at the moment, so this module will inject missing classes and components that may emulate in some way the native enviroment (doing weird things).
• cordova targeting this additional module may rewrite some behaviour to rely on cordova javascript API.

I think we can split our code in these modules, and deploy them as two or three packages :)

Back on the name topic, I think the "web" word is misleading, since we are talking about dom browser component :)

[necolas]

Hi, sorry for the delay getting back to you.

run-time CSS generation: I have an initial implementation of this working in a branch as a replacement for the precomputed CSS library. It doesn't rely on overloading style to accept an array (unlike React Native) but shouldn't be incompatible with that. Styling continues to work if you choose to go 100% inline styles rather than use StyleSheet.

components: I think this is largely what react-native-web is doing; minus iOS/Android-specific props, plus Web-specific props. I'm not as keen on React Native's Touchable components. Not sure why the API is the way it is. I think on Web all those components can be better rolled into a single underlying component. Not sure that the responder system makes sense on Web. And Navigator probably also isn't wanted/needed on Web, where react-router has tackled Web routing pretty comprehensively. There's probably some UI code in this project that makes sense for me to adapt for react-native-web.

apis: I'm hoping that Facebook will individually publish things like Animated so we can depend on them directly. Maybe also things like ListView's datasource code

web-specific components: I think this makes most sense (from a RN perspective) for augmenting browser built-ins for now. For example, ProgressWeb instead of <progress>.

web polyfill: This seems to be the core work you are taking on. Might it even be possible to write this without coupling it to a specific implementation of the Web version of components? I'm not familiar with the problem, because I'm mainly interested in providing the same primitives for web apps, rather than generating web apps from RN projects.

[mattiamanzati]

Yeah I agree. I would like to merge,splitting in the packages discussed before, do you agree?

[necolas]

I don't agree with making the micro modules you proposed.

[chandu0101]

@mattiamanzati @necolas

https://github.com/taobaofed/react-web