what's prevenging Recycle from being just a collection of standard React components? about recycle HOT 5 CLOSED

Here's the biggest concern: the pragma babelrc option is scary. nobody wants to depend on some possible transpilation failure unless it's Facebook insuring it's all going correctly.

from recycle.

as soon as i started to hear that you had a custom compilation step, my interest decreased

from recycle.

Well, I have news!

It was my wish to create this library without the need of pragma transpiler options.
But I just couldn't do it. I also had a good reason why it couldn't be done. I think that was maybe a month ago.

So, I've opened my codebase now so I can answer your question.
But I don't remember what was the reason.

So I tried again.
I can't really believe it yet, so I need to test it out still, but it looks like this is it. All the examples are working! Recycle can now be used as a standard React component.

It was actually very easy.

It looks like I have a lot of work to do for this christmas, mostly on documentation. I guess is not a framework anymore :)

from recycle.

that is very good news. I think u may be on to something then. Don't give up just because initial response wasn't what you wanted. For example, cycle and mobx each struggled for a long time to gain acceptance. I'm actually surprised at how much acceptance Mobx has received. The moral of the story is that Mobx solved some real problems and the shear facts of its benefits prevailed over time. Mobx requires far less recomputation than redux (at least pre react-redux 5.0) because of the depedency graph of computations. And people eventually saw this.

I actually think ur best approach may be to make your "library" feel as small as possible, and sneak it into adoption. As a framework it feels big. So now that it can be a React library again, make it feel as small as possible. So developers have less fear of using it. Make it feel easily replaceable if they want to go back to Redux, etc.

In addition--and this may go against the core goals--but if you can, make it use Redux as a store. Make those serialized actions returned from actions() go to a redux store. For example: I don't wanna give up Redux devtools and time traveling. I have stayed away from observables and preferred sagas for this vary reason. I use the redux devtools and time traveling A LOT. I can't see myself living without it now. I think you want to be in that store. At this moment I'm not sure what features you will have to drop to do that, but I'd seriously think about it. Having a professional interface from observables to redux fulfills a real need.

It seems basically that reducers() would return reducers used by Redux, but your API makes enforces them to be only be able to be used by the component they are attached to.

In addition, you probably need a way for your API (likely your new HOCs) to choose between using local "component-level" reducers and standard redux reducers. All while powering the actions sent to the reducers with observable streams returned from actions().

from recycle.

As of version 0.6.0, Recycle can be used as a standard React library. I've updated the docs, but there is still work to be done for documentation.

Redux plugin should not be a problem to implement, but it would probably use some kind of "recycle-redux bindings". I'm pretty sure it can't be connect-ed like normal React component.
Will let you know when it's done.

from recycle.