Seems outdated?

[wclr]

@staltz This package seems to be a little bit outdated, outdated version of cycle-react dep, deprecated ListView, etc? You don't use it? Seen you've made https://github.com/staltz/cycle-native-navigation

[staltz]

True, this package needs some love. In production I depend on cycle-native-navigation so that's why I haven't myself maintained this one. Help needed, I think.

[wclr]

Ok, probably will make a PR, if will use it.

Why did you decide to make cycle-native-navigation, seems nav/screen handling still is the realm of app logic, though they require additional nav-drivers, it still seems more consistent to use standard approach with run/main/drivers and have some wrapper cycle app that uses drivers and takes some config (for screens/components), if of course there are no limitations that I just don't know about currenlty.

[staltz]

cycle-native-navigation uses react-native-navigation under the hood, which really is a native (Android and iOS) way of having one "app" per "screen". This is a common practice in mobile development where you might need to open a specific screen of an app without opening other parts of the app (e.g. Android Activities). Also, you may have multiple instances of the same screen. This means we need a way of having one set of drivers that are shared among multiple "cycle main" functions, with no predefined "main" "cycle main".

[wclr]

a common practice in mobile development where you might need to open a specific screen of an app without opening other parts of the app

I think in these terms there is no big difference with modern webapps.

Probably need to look at react-native-navigation to make conclusions. But I fill that run/main/drivers basic simple functional approach should be kept here and screens config, layout etc should be provided to some component higher-order factory. And So Main function should take all the drivers and there inside route them if there are not certain technical limitations related to the implementation of rn navigation.

[wclr]

on cycle/react-native

Do you think react-native/react should go to deps or peerDeps what is your reasoning in this question?

[staltz]

@staltz said: This is a common practice in mobile development where you might need to open a specific screen of an app without opening other parts of the app (e.g. Android Activities). Also, you may have multiple instances of the same screen.

Let's call this above "screen orchestration".

@whitecolor said: But I fill that run/main/drivers basic simple functional approach should be kept here and screens config, layout etc should be provided to some component higher-order factory.

If screen orchestration could be done in JS, I agree with you. But the problem is that it's done in Java (Android) or ObjectiveC (iOS), and sometimes even in the OS, so totally outside of our control. I built cycle-native-navigation as a way of adhering to the mobile development "normal" practices as opposed to emulating screen orchestration in JS, with potentially negative effects on user experience. Note that there's also react-navigation for React Native (as an alternative to react-native-navigation), which has a different philosophy, and could maybe be reused for Cycle.js.

PS: I think run/main/drivers functional approach is still kept, there are just multiple main functions, and they communicate with each other via drivers, e.g. a Navigation channel is used to send messages. The architecture isn't that much different, you just have multiple root components, as opposed to the traditional one-root with a tree of children components.

on cycle/react-native

Do you think react-native/react should go to deps or peerDeps what is your reasoning in this question?

peerDeps. That's what I do for cycle-native-navigation, at least.

[wclr]

@staltz Ok, probably react-native-navigation really requires such an approach. Also if you don't use this module, you prefer not to use made function helpers for components but use JSX? Without them, there is no much value in this driver.

[staltz]

I think it's useful (for consistency) for all official Cycle repos to have hyperscript as the default, JSX optional.

[wclr]

@staltz Do you yourself use JSX or hyperscript for RN development?

Potentially cycle/react-native could contain additional modules for different external conventional components, just for user convenience, and allow:

import { DatePicker } from '@cycle/react-native/datepicker'

assuming that @react-native-community/datetimepicker is installed (can be put in optional peerDeps)