i think u should remove the information about the `jsx` param in Hello World

[James Gillmore]

it's just unnecessary confusion at that point in time, especially if the user isn't expected to use it.

[James Gillmore]

i think in general, if you can make this all work in regular React without any of your own custom transpilation, you're on to something.

If the custom transpilation only servers the purpose of being able to tack on reducers and actions methods to each component method, then you're better off just as a library of HOCs. I know the idea is to make this clean flat class with actions and reducers right next to the "render/view" method, but from a marketing perspective I think the cons of having to do custom transpilation and conversion between recycle and react components outweigh that.

I don't see why your framework can't be rewritten as a library of higher order components. I'm sure there is a few more aspects about how you do things which depend on custom transpilation that I'm missing. But I bet we also can come up with solutions for them.

So why not:

connect({
   storePath: 'todos',
   reducers() {},
   actions() {},
})(MyComponent)

of if u wanna look more like Redux:

connect('todos.foo',  actions,  reducers)(MyComponent)

In that case, you're almost identical to Redux, except that you take a key path. And of course actions and reducers mean something different.

I think from a marketing standpoint, your framework could benefit from a familiar interface. It's too bad that we can't have everything on a flat class like your beautiful API, but I also see a single-man project having a hard time competing with the Facebook React Monster. Not without creating a completely different framework. See what I'm saying. You essentially have a hybrid framework. That means you're always gonna be behind any React updates. Etc. This scenario never works out good. It's worse because everyone knows that, so everyone stays away from hybrid projects like that. I know that's my instinct. I won't touch a hybrid project with a 10 foot pole. So that's why it's imperative you make the best part of your "framework" work as "libraries" within React. You're gonna have to forgo some things, but not the important things. The important thing isn't having a flat interface with actions, reducers, initial state and view on it. The important thing is the clear connection of RX observables to the state your components receive.

RX Events/Streams -> Serialized Actions -> Reducers -> Components

In other words, the important thing is the idiomatic seamless interface to express that your library provides.

I think you also should try to make it work with Redux. Redux Devtools is fantastic and people won't wanna leave that behind. I know I don't. What would it take to make your system use the Redux store? I think in general a good combination of RX Streams + Redux is something there would be demand for. I haven't done the research, but does such a product exist?? I think a lot of people are using Redux and thinking the grass may be greener on the other side with Streams. People are wondering what they might be missing. The reality is: if you're not doing anything more than just single time-varying variables, you're fine with promises or await/async or sagas. But, your system actually has made Streams more natural than I've ever seen with React. That's really the thing that intrigued me. I'd like to know that Observables are easily available to me, but without thinking that it requires mixing conflicting paradigms. So if a library like yours made that connection clear to me, I'd be very inclined to use it. That essentially solves my--probably warrantless--insecurity that I'm not using observables :).

Anyway, I'd love to see this in react as a library so i can try it out. Otherwise, I'm not sure I have an appetite to do so :(

[Domagoj Kriskovic]

jsx param is obsolete now.
As for suggested API for connect, I understand it would be more familiar, but I'm against it.

I want every component to have ability of passing props object. There are many things for which that is usefull, for example, store plugin, but also for custom made plugins (I've used it several times)

Another reason why I don't want connect-like API is because is just ugly to me :)